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.
I think if we want a solution that allows old code to work, why not what
Timon suggested? Have a base class for Object (RawObject was suggested)
that does not implement the opFunctions. It would still break code, but
would be easy to fix (just specify your class derives from Object, not
RawObject).
-Steve
