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

[deadalnix]

On 12/07/2012 06:15, Andrei Alexandrescu wrote:
> 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

I also had a tilt on that message. This is after reflexion definitively 
the way to go. metaprogramming rox.