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

[Paulo Pinto]

On Thursday, 12 July 2012 at 08:59:46 UTC, Don Clugston wrote:
> On 12/07/12 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
>
> Well:
> * having opCmp() defined for all objects is just plain weird.
> * toString() is a poor design anyway.
>
> But we'd need to be very careful, this is a very disruptive 
> change.

I don't find them that weird, because many OO languages do have 
them.

But I am fine with the design that feels better in D.

--
Paulo