• Kristian (42/42) Aug 25 2006 I suggest a small change to the current overload hiding rules: final
• Don Clugston (4/18) Aug 25 2006 What about when you add new private functions to the base class? They
• Kristian (4/18) Aug 25 2006 Well, a deriving class cannot call private functions of its base class

Kristian <kjkilpi gmail.com> writes:

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);"
}

Don Clugston <dac nospam.com.au> writes:

Kristian wrote:
 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.)

What about when you add new private functions to the base class? They 
must not be virtual, because an existing derived class might already 
have a function with the same name.

Kristian <kjkilpi gmail.com> writes:

On Fri, 25 Aug 2006 18:20:26 +0300, Don Clugston <dac nospam.com.au> wrote:

 Kristian wrote:
 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.)

 What about when you add new private functions to the base class? They  
 must not be virtual, because an existing derived class might already  
 have a function with the same name.

Well, a deriving class cannot call private functions of its base class  
anyway. I'm not suggesting that private flags should be overruled here;  
all the private functions are hidden in deriving classes as normal.