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
