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