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

[deadalnix]

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

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.