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

[Steven Schveighoffer]

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.

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