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

[Timon Gehr]

On 07/12/2012 06:15 AM, Andrei Alexandrescu wrote:
> Required reading prior to this: http://goo.gl/eXpuX
>
> You destroyed, we listened.
>
> I think Christophe makes a great point.

+1.

> We've been all thinking inside
> the box but we should question the very existence of the box. Once the
> necessity of opCmp, opEquals, toHash, toString is being debated, we get
> to some interesting points:
>
> 1. Polymorphic comparisons for objects has problems even without
> considering interaction with qualifiers. I wrote quite a few pages about
> that in TDPL, which add to a lore grown within the Java community.
>
> 2. C++ has very, very successfully avoided the necessity of planting
> polymorphic comparisons in base classes by use of templates. The issue
> is template code bloat. My impression from being in touch with the C++
> community for a long time is that virtually nobody even talks about code
> bloat anymore. For whatever combination of industry and market forces,
> it's just not an issue anymore.
>
> 3. opCmp, opEquals, and toHash are all needed primarily for one thing:
> built-in hashes. (There's also use of them in the moribund .sort
> method.) The thing is, the design of built-in hashes predates the
> existence of templates. There are reasons to move to generic-based
> hashes instead of today's runtime hashes (such as the phenomenal success
> of templated containers in C++), so it can be argued that opCmp,
> opEquals, and toHash exist for reasons that are going extinct.
>
> 4. Adding support for the likes of logical constness is possible, but
> gravitates between too lax and onerously complicated. Walter and I don't
> think the aggravation is justified.
>
> There are of course more angles and considerations. Walter and I
> discussed such for a while and concluded we should take the following
> route:
>
> 1. For the time being, rollback the changes. Kenji, could you please do
> the honors? There's no need to undo everything, only the key parts in
> object.d. Apologies for having to undo your work!
>
> 2. Investigate a robust migration path from the current use of opCmp,
> opEquals, toHash (we need to also investigate toString) to a world in
> which these methods don't exist in Object. In that world, associative
> arrays would probably be entirely generic. Ideally we should allow
> existing code to still work, while at the same time fostering a better
> style for new code.
>
>
> What say you?
>
> Andrei

Thank you for taking the time.

Removing the default methods completely is actually a lot better than 
making inheriting from Object optional or tweaking const beyond 
recognition and/or usefulness.
I was afraid to suggest this because it breaks all code that assumes
that the methods are present in object (most code?), but I think it is
a great way to go forward.

Regarding toString, getting rid of it would imply that the default way
of creating a textual representation of an object would no longer be
part of Object, paving the way for the proposal that uses buffers and
scope delegates - this will be purely a library thing.

Regarding backwards-compatibility, an issue that is trivial to fix is
the invalidation of 'override' declarations in the child classes.
They can be allowed with the -d switch for those methods. And if they
use 'super', the compiler could magically provide the current default
implementations.