ProtoObject and comparison for equality and ordering
SimonN
eiderdaus at gmail.com
Wed May 15 12:46:04 UTC 2019
On Wednesday, 15 May 2019 at 07:10:44 UTC, Dominikus Dittes
Scherkl wrote:
> On Tuesday, 14 May 2019 at 20:36:08 UTC, Eduard Staniloiu wrote:
>> (comparing two `ProtoObject`s) we can not establish any
>> relationship between the two, the `__cmp` lowering won't be
>> able to compare two.
> That's ok. Why should anybody expect that two arbitrary things
> should have an ordered relation? Is egg > apple? And in what
> way? Is it heavier? longer? older? better? has more calories?
>> Since we are here, I want to raise another question:
>> Should `opCmp` return a float?
> Yes, please!
> I need unordered relations so often (see above)!
It's fine if we can add a partial order to some classes, or a
linear order to other classes. There can be two static
introspections/two interfaces for these two orderings. (And
linear orders also qualify as partial orders during
introspection.)
Comparing two objects from a partial order, such a comparison
should be able to yield uncomparable, no problem.
Comparing two objects from two different class hierarchies that
define two unrelated partial orders, I don't have an opinion on
whether this should compile, or whether it may even return that
one is greater than the other.
Comparing two ProtoObjects should always be a compilation error.
We should not assume partial orders everywhere. That can lead to
roundabout code: Linear orders are common, and I don't want to
handle any uncomparable case for linear orders. And readers of my
code should immediately see that there is no bug here, i.e., that
I didn't forget to think about the uncomparable case.
Thus I wouldn't change int opCmp to float opCmp -- for linear
orders, I like a static guarantee that different objects are
always comparable and never NaN.
-- Simon
More information about the Digitalmars-d
mailing list