restructuring name hiding around the notion of hijacking

Max Samukha spambox at d-coding.com
Fri Oct 2 05:29:09 PDT 2009


On Thu, 01 Oct 2009 22:52:28 -0500, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:

>Michel Fortin wrote:
>> On 2009-10-01 12:29:39 -0400, Andrei Alexandrescu 
>> <SeeWebsiteForEmail at erdani.org> said:
>> 
>>>> I think it's a good idea, but there should be a way to *override* 
>>>> static functions.
>>>
>>> That has the same risks. The problem right now is that in order to use 
>>> a class, you must absorb the definition of that class and that of each 
>>> superclass of it, all the way up to Object. With hijacking thwarted, 
>>> you can specify stuff in the base class that you can be sure will 
>>> continue to work the same in derived classes. I believe this makes 
>>> using classes quite a lot easier and safer.
>> 
>> But it breaks one pattern of mine. In the D/Objective-C bridge I have a 
>> few static functions and variables that must be redefined for each 
>> subclass defining an Objective-C interface.
>
>I'd say that's a questionable practice (but then I don't know any more 
>details).
>
>Andrei

It may be questionable but it is used quite often. The technique can
be illustrated by altering your example of automatic code injection:

class Counted {
     mixin(Derived)
     {
         // Insert here stuff that must be "pasted" for each subclass
         // of Counted (including Counted itself).
         // Use "Derived" as the name of the current subtype of
Counter
         private static uint _counter;
         uint staticCounter() { return _counter; } 

         static if (is(Counted == Derived))
             uint getCounter() { return staticCounter; }
         else
             override uint getCounter() { return staticCounter; }
     }
     ...
}

The counter variable is now incapsulated.

If the counter is, for example, an object that should be lazily
created, then you cannot get away without the static function any
more.

BTW, your example shows that 'override' being optional may actually be
a good idea and in this particular case allows to avoid the static
check and code duplication



More information about the Digitalmars-d mailing list