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

[Steven Schveighoffer]

On Thu, 12 Jul 2012 14:43:57 -0400, Jacob Carlborg <doob at me.com> wrote:

> On 2012-07-12 15:39, Steven Schveighoffer wrote:
>
>> 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).
>
> Wouldn't the default be to inherit from Object?
>
> Like this:
>
> class RawObject {}
> class Object : RawObject {}
> class Foo {} // inherits from Object by default.
>
> Most people would not need to change anything, they can continue to use  
> Object. If they want to avoid the methods declared in Object they need  
> to explicitly inherit from RawObject.

Many (most?) classes never care about opHash, opCmp, opEquals and  
toString.  But Object defines them, incorrectly for most cases.

These apathetic classes would not break at all.  And to make the default  
be to inherit those methods would promote their usage or reliance on them.

Not only that, but you are almost *forced* to define them, because you  
don't want accidental incorrect usage of them.  We have lovely situations  
where the only solution is to define a version of the method that *always  
throws* in a statically typed language.

It's really a terrible solution (to force the definition of them) which  
Andrei quite correctly pointed out only existed because of the lack of  
templates back then.

I think this discussion is somewhat academic at this point, as Andrei  
seems not too keen on the idea of having dual base classes.

-Steve