Why do we really need this strange overloading, reimplementation rules. It is so annoying.

If you overload a method from a base class you hide the base method. To
avoid this you need to do an alias.
alias Base.fnc fnc;

If more than one version of fnc exists, you cannot specify which one shall be alias.

There is no advantage in this. Without this rule, you can probably overload instead of the intended override (But we already have the override keyword, make it required?). With this rule, you probably hide an existing base implementation and probably change the behaviour of the class, if the overloaded function is compatible to the base version. (e.g. visitor pattern).

Another pain point: Why do we really need to reimplement a method if an
interface is again used?
interface I{ void fnc(); }
class B : I { void fnc(){} }
class C : B, I { } // error needs to reimplement fnc.

Frank Benoit (keinfarbton) wrote:
> Why do we really need this strange overloading, reimplementation rules.
> It is so annoying.
>
> If you overload a method from a base class you hide the base method. To
> avoid this you need to do an alias.
> alias Base.fnc fnc;

It can be a bit annoying at times, yes.

> If more than one version of fnc exists, you cannot specify which one
> shall be alias.

If you aliased an overloaded function or method name, you alias *all* the overloaded versions:
---
urxae@urxae:~/tmp$ cat test.d
import std.stdio;

class Base {
    void foo(int) { writefln("foo(int)"); }
    void foo(char[]) { writefln("foo(char[])"); }
}

class Derived : Base {
    void foo(float) { writefln("foo(float)"); }
    alias Base.foo foo;
}

void main(){
    Derived d = new Derived;
    d.foo(1);
    d.foo("bar");
    d.foo(1.0);
}
urxae@urxae:~/tmp$ dmd -run test.d
foo(int)
foo(char[])
foo(float)
---

Judging by your views on the rest of this matter, I think you will agree that this is usually what you want to do.

However, this seems to be another manifestation of the inability to specify specific overloads that is also so annoying when trying to take a function pointer (or in this case delegate) of an overloaded function/method.
A syntax for this has been proposed (e.g. &d.foo(int)) but I don't recall Walter responding to it. (If he did, it probably wasn't positively or I would have remembered)

> There is no advantage in this. Without this rule, you can probably
> overload instead of the intended override (But we already have the
> override keyword, make it required?). With this rule, you probably hide
> an existing base implementation and probably change the behaviour of the
> class, if the overloaded function is compatible to the base version.
> (e.g. visitor pattern).


> Another pain point: Why do we really need to reimplement a method if an
> interface is again used?
> interface I{ void fnc(); }
> class B : I { void fnc(){} }
> class C : B, I { } // error needs to reimplement fnc.

I can understand this one, actually. The way I see it, the only reason to reimplement an interface is to make sure it remains implemented even if the base class is modified. So the only way to keep it compiling if the interface is removed from the base class is to ensure you provide implementations.
On the other hand, an argument could be made that compile-time errors ("interface method not implemented: 'I.fnc'") would be appropriate in this case...

My point is, i want this strange rules to be removed.
And I want the override keyword not to be a useless thing.

I propose:
1.) make an overload not hide base implementations
2.) make the override keyword required, to make it useful.
3.) remove the interface reimplementation rule.

What do you think?

Frank Benoit (keinfarbton) wrote:

> 
> My point is, i want this strange rules to be removed.
> And I want the override keyword not to be a useless thing.
> 
> I propose:
> 1.) make an overload not hide base implementations

votes++

> 2.) make the override keyword required, to make it useful.

Not so sure about this one. It will introduce a lot of unnecessary typing and that can be annoying if you want the function prototypes to fit into 80 characters.

> 3.) remove the interface reimplementation rule.

Definitely a good idea.

> 
> What do you think?

>> 2.) make the override keyword required, to make it useful.
> 
> Not so sure about this one. It will introduce a lot of unnecessary typing and that can be annoying if you want the function prototypes to fit into 80 characters.

I think in any bigger software, the keyword override should be used consequently. It makes sure that a typo doesn't makes an overload instead of an override and vice versa. Which is a bug, very hard to find.

But actually this works only in one direction (1) and it cannot be enforced.

(1) Only in one direction means, you can make sure your override is an override, but you cannot make sure your overload is an overload. If "override" would be required, this check works in both directions. (no "override" means, its a not an override)

Another advantage is, in big programs, classes with many methods. You can be sure that a overridden method is marked as such. That make understanding of code easier.

I think every good editor can assist here very good and I believe, the benefit of an explicit "override" is higher than the cost of typing/autocompleting it.

Frank Benoit (keinfarbton) wrote:

> 
> My point is, i want this strange rules to be removed.
> And I want the override keyword not to be a useless thing.
> 
> I propose:
> 1.) make an overload not hide base implementations
> 2.) make the override keyword required, to make it useful.
> 3.) remove the interface reimplementation rule.
> 
> What do you think?

I agree strongly with all 3 above. And 2) will be a unique help for any program that are to be mantained for any amount of time. It is nothing but an extension to the already existing contracts. Mantainable programs are another area where D can shine, but then we need to take opportunities like this.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Frank Benoit (keinfarbton) wrote:

> 
>>> 2.) make the override keyword required, to make it useful.
>> 
>> Not so sure about this one. It will introduce a lot of unnecessary typing and that can be annoying if you want the function prototypes to fit into 80 characters.
> 
> I think in any bigger software, the keyword override should be used consequently. It makes sure that a typo doesn't makes an overload instead of an override and vice versa. Which is a bug, very hard to find.
> 
> But actually this works only in one direction (1) and it cannot be
> enforced.
> 
> (1) Only in one direction means, you can make sure your override is an override, but you cannot make sure your overload is an overload. If "override" would be required, this check works in both directions. (no "override" means, its a not an override)
> 
> Another advantage is, in big programs, classes with many methods. You can be sure that a overridden method is marked as such. That make understanding of code easier.
> 
> I think every good editor can assist here very good and I believe, the benefit of an explicit "override" is higher than the cost of typing/autocompleting it.

I'm more concerned about redability when the lines get to long than typing. And I also don't think that enforcement of overload/override is that important, no other language I have used does this and if a class have so many methods that they cant be kept track of is probably missdesigned.

Johan Granberg wrote:

> Frank Benoit (keinfarbton) wrote:
> 
>> 
>>>> 2.) make the override keyword required, to make it useful.
>>> 
>>> Not so sure about this one. It will introduce a lot of unnecessary typing and that can be annoying if you want the function prototypes to fit into 80 characters.
>> 
>> I think in any bigger software, the keyword override should be used consequently. It makes sure that a typo doesn't makes an overload instead of an override and vice versa. Which is a bug, very hard to find.
>> 
>> But actually this works only in one direction (1) and it cannot be
>> enforced.
>> 
>> (1) Only in one direction means, you can make sure your override is an override, but you cannot make sure your overload is an overload. If "override" would be required, this check works in both directions. (no "override" means, its a not an override)
>> 
>> Another advantage is, in big programs, classes with many methods. You can be sure that a overridden method is marked as such. That make understanding of code easier.
>> 
>> I think every good editor can assist here very good and I believe, the benefit of an explicit "override" is higher than the cost of typing/autocompleting it.
> 
> I'm more concerned about redability when the lines get to long than typing. And I also don't think that enforcement of overload/override is that important, no other language I have used does this and if a class have so many methods that they cant be kept track of is probably missdesigned.

That no other language you've used has it is hardly a good reason. It isn't to keep track of said methods, but to bind them to a contract that can be enforced like interfaces, DbC and unittests.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Johan Granberg wrote:
> Frank Benoit (keinfarbton) wrote:
> 

> I'm more concerned about redability when the lines get to long than typing.

public override
int some_method_with_a_long_name(and with, lots of, parameters too);

??

> And I also don't think that enforcement of overload/override is that
> important, no other language I have used does this and if a class have so
> many methods that they cant be kept track of is probably missdesigned. 

I don't think it's so much a matter of having too many methods to keep track of, but just not realizing there's a method there you're shadowing, or accidentally getting the argument types slightly wrong.

--bb

Lars Ivar Igesund wrote:
> Frank Benoit (keinfarbton) wrote:
> 
>> My point is, i want this strange rules to be removed.
>> And I want the override keyword not to be a useless thing.
>>
>> I propose:
>> 1.) make an overload not hide base implementations

What does this mean when combined with number 2?

class Base
{
   int foo(int) { ... }
}
class Derived : Base
{
   // Is this "error: override keyword required"
   // Or is it ok -- not an override but a distict overload leaving
   // foo(int) in tact.
   int foo(float) { ... }
}

If the above code requires 'override' then the meaning of 'override' is getting stretched too far.  I that case it isn't overriding anything.

If the above code is OK as is, then that's also a problem because one of the most common bugs with overriding is getting the signature wrong.  I guess if override is required for actual overriding that means the above coder was actually making two mistakes -- forgetting to say 'override' *and* getting the signature wrong, but I don't think that combination of mistakes would be terribly uncommon.

In short, the above code looks like it's probably a coder error and the coder meant to override foo(int).  But you can't be sure.

>> 2.) make the override keyword required, to make it useful.

+1

But note above about not playing nice with exposed base implementations.  If overloaded base implementations were not automatically inherited then the above would actually give a useful error because foo(float) is hiding (and thereby overriding) foo(int), though it is not declared 'override'.

>> 3.) remove the interface reimplementation rule.

That sounds ok to me -- actually my naive expectation was that that was how interfaces already worked.

--bb