aliasing base methods

[Bill Baxter]

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