restructuring name hiding around the notion of hijacking

[Michel Fortin]

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. With your proposal I'd have 
to give them a different name for each subclass.

For instance, the "objcClass" function in:

	NSObject.objcClass

will give you a pointer to the Objective-C class NSObject, while in:

	NSString.objcClass

it will give you a pointer to the Objective-C class NSString, because 
objcClass has been reimplemented in the D version of the NSString class 
even though it derives from NSObject which has its own.

If you can't override a static function, how do you implement this?

I'd suggest that a static function could be made final which would 
remove the possibility of redefining it in a subclass. But in abscence 
of "final", you should still be able to "override" a static function in 
a subclass (perhaps the override keyword should be required).

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