inherit, override, overload

[Kristian Kilpi]

Hmm, was this (see the old post below) the only reason to hide derived  
functions (or do I remember incorrectly)?

I mean, the same problem occurs, of course, with any class, are they  
derived or not. For example, a library provides the Base class which one  
uses as follows:

     class Base {
       void f(int);
     }

     class Derived : Base {
       void f(int);  //override the base function
     }

     Base b = new Base;
     Derived d = new Derived;
     char ch;

     b.f(ch);
     d.f(ch);

Now, when 'f(char)' is added to Base, 'b.f(ch)' will call it instead of  
'f(int)'. So it can cause problems anyway. I just think that it's odd that  
Derived won't have the same functions as Base, it's derived from it after  
all. And what if one had used Derived via Base, e.g:

   void func(Base b) {
     char ch;
     b.f(ch);
   }

   Derived d = new Derived;
   char ch;

   func(d);  //calls f(char)
   d.f(ch);  //calls f(int)

, which is inconsistent. I would prefer the same behaviour throughout my  
program.



On Sun, 10 Dec 2006 23:42:53 +0200, Kristian Kilpi <kjkilpi at gmail.com>  
wrote:
> On Sun, 10 Dec 2006 20:24:14 +0200, Frank Benoit (keinfarbton)  
> <benoit at tionex.removethispart.de> wrote:
>
>> I posted about that on Nov. 13th already in "override and overload". But
>> I did not got any response. Apologies for posting again.
>>
>> Since I first read about the mechanism, how D resolves overloads and
>> override, I think this is not the best solution.
>>
>> See http://www.digitalmars.com/d/function.html
>> .... To consider the base class's functions in the overload resolution
>> process, use an AliasDeclaration
>>
>> I want to suggest the following:
>> 1.) change the overloading rule, so it does not hide the derived methods
>> in every case.
>> 2.) make keyword "override" required for all overriding methods. Throw a
>> compiler error if the "override" keyword is missing.
>> 3.) For consistency, require also "override" if implementing a interface
>> or abstract method.
>>
>> Now overloading is possible without doing the alias and the code is more
>>  telling about which methods are used polymorph.
>>
>> What do you think?
>>
>
> Changes to the overloading rules has been proposed before, which isn't a  
> surprise <g>. Actually I also have suggested earlier that overloading  
> would not hide the derived functions. It was explained that the function  
> hiding is a good thing(tm) because if it was not done, then adding new  
> function overloads to the base class could cause bugs or malfunctions in  
> the program using it. For example:
>
>    class Base {
>      void f(int);
>    }
>
>    class Derived : Base {
>      void f(int);  //override the base function
>    }
>
>    Derived d = new Derived;
>    char ch;
>
>    d.f(ch);  //calls f(int)
>
> Now, the Base class is changed (e.g. Base is provided in a libary):
>
>    class Base {
>      void f(int);
>      void f(char);
>    }
>
>    d.f(ch);  //calls f(char) instead of f(int)
>
> So this can introduce bugs in your program.
>
> Well, any modifications done to base classes can cause bugs in classes  
> derived from them. And I think it's good programming style to use  
> excplicit type conversions:
>
>    d.f(cast(int)ch);
>
> and we would have no problems.
>
>
> You can of course use an 'alias hack' currently to prevent derived  
> functions from being hidden. So, it would be nice to have a better  
> syntax or a shorthand for it (because sometimes you indeed want that the  
> derived functions will not be hidden). The override keyword could be  
> changed so that it would not hide functions (haven't think implications  
> of it though). Or we could have a new keyword for it, e.g. overrule.