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

[Paulo Pinto]

On Thursday, 12 July 2012 at 11:03:37 UTC, Don Clugston wrote:
> 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???

Silly me. I forgot that in D opCmp is more than just equality.

toString() I find it helpful specially in the cases where objects 
don't give enough external information. This is usable in 
scenarios where printf debugging is the only way.

Then again, it relies on the developer to have written a sensible 
toString() to start with.

On second thought you're probably right.

--
Paulo