On Thu, 12 Jul 2012 14:43:57 -0400, Jacob Carlborg <d...@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
