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

[Andrei Alexandrescu]

On 7/12/12 9:39 AM, Steven Schveighoffer wrote:
> On Thu, 12 Jul 2012 09:20:47 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> 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.

> 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).

Too complicated. I think we can afford one comparison.


Andrei