View mode: basic / threaded / horizontal-split · Log in · Help
February 26, 2007
Re: aliasing base methods
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
February 26, 2007
Re: aliasing base methods
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)
February 26, 2007
Re: aliasing base methods
>> 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.
February 26, 2007
Re: aliasing base methods
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
February 26, 2007
Re: aliasing base methods
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
Next ›   Last »
1 2 3
Top | Discussion index | About this forum | D home