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

Don Clugston dac at nospam.com
Thu Jul 12 04:03:36 PDT 2012


On 12/07/12 12:00, Paulo Pinto wrote:
> 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.

Really? I find that incredible. Ordered comparisons <, > don't even make 
sense for many mathematical objects!
You can't even define opCmp for a float.

Object f = new FtpConnection;
Object e = new Employee("Bob");
if (f > e)  // Huh???




More information about the Digitalmars-d mailing list