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

[Andrei Alexandrescu]

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