restructuring name hiding around the notion of hijacking

[Michel Fortin]

On 2009-10-01 23:52:28 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> 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).

Well, essencially you can have a D class that act as a wrapper to an 
Objective-C class, or you can also have the reverse: a D class exposing 
itself as an Objective-C class. In all cases, the type hiearchy is 
preserved, so if you have NSString as a subclass of NSObject on the 
Objective-C side, you'll have the same on the D side.

The NSString wrapper must have different static members than NSObject, 
binding it to a different Objective-C class so it can call the right 
methods on it (and so it allocates the right function), but those 
members have the same role (just a different value per class) and must 
be accessible for any class declaring an Objective-C interface (so the 
bridge can swap between the Objective-C and D value when calling a 
function on the other side).

So it turns out that I'm implementing a mechanism somewhat alike 
classinfo for storing Objective-C related class-level data, and for 
that to work I need to reimplement any function accessing this data in 
each subclass that binds to a different Objective-C class.

If I could attach my class-related data to the ClassInfo of a specific 
class (so it could be retrieved at runtime) and if static functions had 
access to the classinfo of the class they're called from (practically 
making them member function of the corresponding ClassInfo) the 
situation might be different though, and much less code would be needed.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/