• Frank Benoit (keinfarbton) (17/17) Dec 10 2006 I posted about that on Nov. 13th already in "override and overload". But
• Kristian Kilpi (46/63) Dec 10 2006 ut
• Kristian Kilpi (51/109) Dec 11 2006 Hmm, was this (see the old post below) the only reason to hide derived ...

"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?

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

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

ds
 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 interfa=

ce
 or abstract method.

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

re
  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.

"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". =


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


n
 process, use an AliasDeclaration

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


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


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


ace
 or abstract method.

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


ore
  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 functi=

on  =

 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  =

 syntax or a shorthand for it (because sometimes you indeed want that t=

he  =

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

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

s  =

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