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

kenji hara k.hara.pg at gmail.com
Thu Jul 12 07:28:18 PDT 2012


Is this really need?

The four const operators in Object should not block the user-defined
mutable operators.

// My purpose for 2.060 release
class C {
  override opEquals(const Object o) const { ... } // or just alias
super.opEquals opEquals;
  bool opEquals(Object o) { ... } // add overload for mutable object comparison
}

auto c1 = new C(), c2 = new C2();
c1 == c2;   // the both hand side is mutable, so mutable opEquals will run

In git head, it is not disallowed, but it is a *compiler bug*.
To fix the problem, I have a pull request for dmd.
https://github.com/D-Programming-Language/dmd/pull/1042
(The pull will kill attribute inference for const, but I think it is
unnecessary for D.)

...But, I would never opposed to advancing toward the better language design.

Kenji Hara

2012/7/12 Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:
> 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


More information about the Digitalmars-d mailing list