www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - inherit, override, overload

reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
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?
Dec 10 2006
parent reply "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Sun, 10 Dec 2006 20:24:14 +0200, Frank Benoit (keinfarbton)  =

<benoit tionex.removethispart.de> wrote:

 I posted about that on Nov. 13th already in "override and overload". B=

 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 metho=

 in every case.
 2.) make keyword "override" required for all overriding methods. Throw=

 compiler error if the "override" keyword is missing.
 3.) For consistency, require also "override" if implementing a interfa=

 or abstract method.

 Now overloading is possible without doing the alias and the code is mo=

  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 =3D 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 synta= x = or a shorthand for it (because sometimes you indeed want that the derive= d = 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.
Dec 10 2006
parent "Kristian Kilpi" <kjkilpi gmail.com> writes:
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 =3D new Base;
     Derived d =3D 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 th=
at  =

Derived won't have the same functions as Base, it's derived from it afte=
r  =

all. And what if one had used Derived via Base, e.g:

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

   Derived d =3D 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 gmail.com>  =

wrote:
 On Sun, 10 Dec 2006 20:24:14 +0200, Frank Benoit (keinfarbton)  =

 <benoit tionex.removethispart.de> wrote:

 I posted about that on Nov. 13th already in "override and overload". =


 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 resolutio=


 process, use an AliasDeclaration

 I want to suggest the following:
 1.) change the overloading rule, so it does not hide the derived meth=


 in every case.
 2.) make keyword "override" required for all overriding methods. Thro=


 compiler error if the "override" keyword is missing.
 3.) For consistency, require also "override" if implementing a interf=


 or abstract method.

 Now overloading is possible without doing the alias and the code is m=


  telling about which methods are used polymorph.

 What do you think?

Changes to the overloading rules has been proposed before, which isn't=

 surprise <g>. Actually I also have suggested earlier that overloading =

 would not hide the derived functions. It was explained that the functi=

 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 =

 the program using it. For example:

    class Base {
      void f(int);
    }

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

    Derived d =3D 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 t=

 derived functions will not be hidden). The override keyword could be  =

 changed so that it would not hide functions (haven't think implication=

 of it though). Or we could have a new keyword for it, e.g. overrule.

Dec 11 2006