All right, all right! Interim decision regarding qualified Object methods

[Daniel Kozak]

On Thursday, 12 July 2012 at 13:20:47 UTC, Andrei Alexandrescu 
wrote:
> On 7/12/12 3:59 AM, Jonathan M Davis wrote:
>> If you can figure out how to make this work, it's fine by me.
>>
>> However, I see two potential issuses which cause currently 
>> working idioms to
>> no longer work:
>>
>> 1. Anything which wants to be able to operate on Objects 
>> generically (e.g.
>> have a container full of Objects) is going to have problems, 
>> since comparison
>> and hashing won't work anymore. For the standard stuff, at 
>> minimum, that will
>> screw up being able to put Object in AAs and RedBlackTree. For 
>> 3rd party
>> containers which decided to go the Java route of containing 
>> Objects, they risk
>> being completely screwed.
>
> I've been thinking more about this and it's possible to keep 
> good backwards compatibility by "marginalizing" instead of 
> eliminating the four culprits.
>
> Consider:
>
> class A { void fun() {} }
> class B : A { void fun() {} }
> class C : A {}
> void main() {
>     A objA = new A;
>     A objB = new B;
>     A objC = new C;
>     assert((&objA.fun).funcptr != (&objB.fun).funcptr);
>     assert((&objA.fun).funcptr == (&objC.fun).funcptr);
> }
>
> In brief there _is_ a way to check during runtime whether a 
> class has overridden a method.
>
> If we define alternative free generic functions in object.d for 
> the four culprit methods (and have the compiler, druntime, and 
> stdlib use them instead of the methods), those functions can 
> check whether a given class object has overridden the old-style 
> functions. In that case, that means we're dealing with legacy 
> classes and proceed the old-style way. Otherwise, proceed the 
> new way.
>
>
> Andrei


+1