On 12/07/2012 15:49, Andrei Alexandrescu wrote:
On 7/12/12 9:39 AM, Steven Schveighoffer wrote:
On Thu, 12 Jul 2012 09:20:47 -0400, Andrei Alexandrescu
<[email protected]> 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.
Hm... I don't like this, it slows down a very basic function.
It's one comparison.
And one branching. In itself it isn't high cost, but can become a
problem in a tight loop, say a sort function for instance.
