Suggestion: overruling should not hide final overload functions

Kristian kjkilpi at gmail.com
Fri Aug 25 06:55:09 PDT 2006


I suggest a small change to the current overload hiding rules: final  
functions should not be hidden.

Logic behind this is the following:
You can make a function final only when you know for sure that there is no  
need to change its behavior later in a deriving class.

If you cannot be absolutely sure, then the function must not be final.


That means that changing the implementation of a final function must not  
-- and cannot -- change behavior of deriving classes. (Usually this also  
means that there will be no need to change the implementation of final  
functions anyway.)

Hence final functions should not be included in the overload hiding rules.
The rules are applied because changes made to the base can make deriving  
classes work incorrectly. Final functions, by 'definition', do not cause  
that, ever. So, there is no reason to hide them in deriving classes.


For example, commonly used 'convenience' functions can be made final:

class String {...}

class Base {
      void f(String s) {...}
      //these functions are provided for convenience...
      final void f(int v) {
          f(new String(v));
          }
      final void f(float v) {
          f(new String(v));
          }
}

class Derived : Base {
      void f(String s) {...}  //overrule the main function that does all  
the work
}

It would be great if there would be no need to alias hack such functions.  
Especially because alias hacking can have side-effects. For example, if  
you alias hack the convenience functions to Derived, and a new non-final  
function 'f()' is later added to Base, then that new function would  
callable via Derived. It shouldn't be by the current & modified overload  
hiding rules.


By 'alias hack' I mean the following:

class Derived : Base {
      void f(String s) {...}
      alias Base.f f;         //now you can call "Derived d; d.f(10);"  
instead of "d.Base.f(10);"
}



More information about the Digitalmars-d mailing list