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
