how to fix such a hijacking problem in D ?

Bill Baxter dnewsgroup at billbaxter.com
Sun Dec 16 04:05:06 PST 2007


Bill Baxter wrote:
> z_axis wrote:
>> import std.stdio;
>>
>> class A
>> {
>>     void foo(long) {}
>>     void def() { writefln("A.def()"); foo(1L); }  // expects to call 
>> A.foo(long)
>> }
>>
>> class B : A
>> {
>>     void foo(long) { writefln("B.foo()"); };    // will hijack A's foo()
>> }
>>
>> void abc(B b)
>> {       b.def();
>> }
>>
>>
>> void main(char[][] args)
>> {      abc(new B);
>> }
>> output:
>> A.def()
>> B.foo()
>>
>> The B will hijack the A's foo(long) ?!
>>
>> any suggestion ?
> 
> 
> I think "final" is for that.  Says that the method should not be virtual 
> (virtual is the default in D).
> 
>    final void foo(long) {...}
> 
> Not sure if that works, since it's actually not documented as far as I 
> can tell.  But DFL uses 'final' a lot so I'd guess it does something. Or 
> else DFL is just deluding itself.
> 
> Another option would be to rename them per-class, or use "static" if you 
> don't actually need the 'this' pointer.

Another option would be to make foo(long) a template, since those can't 
be virtual.

    void foo()(long) {}

--bb


More information about the Digitalmars-d-learn mailing list