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

[Andrei Alexandrescu]

Required reading prior to this: http://goo.gl/eXpuX

You destroyed, we listened.

I think Christophe makes a great point. 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