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

[Steven Schveighoffer]

On Thu, 12 Jul 2012 09:49:29 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

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

I don't know if it's one comparison, and really, we are doubling the  
vtable lookups.  I think the compiler should be able to optimize to one  
vtable lookup.

Aside from this, the baggage of four dead functions in every vtable is  
pretty hefty, is there a path to deprecation, or are the four horseman of  
the const apocalypse going to exist forever?  It would suck to have to  
deal with these issues forever.

-Steve