Frank Benoit (keinfarbton) wrote:
>> Another thought -- making override required could make life difficult
>> for some code generators.  Imagine an automatic class wrapper that
>> creates a derived class of the form:
>>
>> class foo(Base)  : Base
>> {
>>    int someMethod(int x) { ... }
>> }
>>
>> That will always work now, but if override becomes required, then that
>> template will have to do some static if mojo to figure out if Base
>> already has a someMethod(int) implemented or not and if so stick in the
>> 'override'.
> 
> No, it will not work.
> Today you also need to know the base class methods, and add aliases in
> you generated class, if needed. 
> The problem is exactly the same. TioPort
> actually implements this.

Good point.

> For generated code, it is probably easier this way with override.
> Because if you generate code, you most of the time know, that you do a
> override.

Not necessarily.  The foo(Base) class could be trying to apply a uniform interface to something, and not care whether base class methods are being reimplemented/hidden or not.  This is more or less the case with policy-based design.  http://en.wikipedia.org/wiki/Policy-based_design
The policy implementers just need to have the methods required by the policy, but they could also have other methods too.  The interface in the end, though, is supposed to be what the base class presents to the world, and you don't generally care if you're hiding methods or not.
(Of course Policy based design is not as useful in D because there's no multiple inheritance -- maybe Andrei can comment more on alternatives ;-) )

> To the ambiguity issue of the alias:
> Override is always/already precise, because it *is* bundled with the
> complete method signature.

Don't follow you there.

--bb

Bill Baxter wrote:
> (Of course Policy based design is not as useful in D because there's no multiple inheritance -- maybe Andrei can comment more on alternatives ;-) )

Actually, you can probably implement it with alias template parameters and mixins. (Pass templates by alias and mix them in)

>> To the ambiguity issue of the alias:
>> Override is always/already precise, because it *is* bundled with the
>> complete method signature.
> 
> Don't follow you there.

My point was, that the alias is actually not precise, but the override already is.

If you alias a method, it can be ambiguous, because you do not specify which version you want to alias. You would need to extend the syntax to make is precise.

alias Base.fnc fnc;      // all fnc (not precise)
alias Base.fnc(int) fnc; // exactly this fnc. (precise)

In the opposite, the override keyword is already precise, because it is the method signature.

override void fnc( float ){ ... }

No change in syntax needed.

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

Definitely. Imho, hiding them achieves nothing except annoyance.. Though, if I recall correctly, the argument for hiding is the following - if the base class gets a method with the same name, users of the derived class will start calling the new method in some cases, most probably causing trouble (as the derived class now doesn't override the new method, even if it previously did override all other methods with the same name).

But, it seems that most people don't expect the hiding to happen, and the alias workaround just seems wrong somehow, at least to me. So, why not introduce some new syntax?

class Derived : Base {
    override foo; // I declare that I'll be overriding all foos

    // override no longer needed here or in other foos, even
    // if override is made mandatory
    public void foo(int i) { .. }
}

Problem solved :)


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

+1


> 3.) remove the interface reimplementation rule.

Well, it can be useful in similar cases as for 1, so why not remove reimplementation requirement by default, but with the option of

class NewFoo : OldFoo, override IFoo
{
   // reimplementation required
}


xs0

Frank Benoit (keinfarbton) wrote:
>>> To the ambiguity issue of the alias:
>>> Override is always/already precise, because it *is* bundled with the
>>> complete method signature.
>> Don't follow you there.
> 
> My point was, that the alias is actually not precise, but the override
> already is.
> 
> If you alias a method, it can be ambiguous, because you do not specify
> which version you want to alias. You would need to extend the syntax to
> make is precise.
> 
> alias Base.fnc fnc;      // all fnc (not precise)
> alias Base.fnc(int) fnc; // exactly this fnc. (precise)
> 
> In the opposite, the override keyword is already precise, because it is
> the method signature.
> 
> override void fnc( float ){ ... }
> 
> No change in syntax needed.

Ok.  I see what you mean now.  But one way or another we're going to have to fix the alias mess.  Not being able to alias a particular version of an overloaded function is just too much of a gaping hole.

--bb