Why keep identity-based equality comparison?

[Antoon Pardon]

Op 2006-01-12, Mike Meyer schreef <mwm at mired.org>:
> Antoon Pardon <apardon at forel.vub.ac.be> writes:
>> Op 2006-01-11, Mike Meyer schreef <mwm at mired.org>:

[ BIG CUT ]

I'm going to drop this part. I disagree with you and think
I can show some of your argument invalid. Hoever I also doubt
something fruitfull can come from continuing this. Lets agree
to disagree.

>> IMO it would be better if it was possible to associate some kind
>> of order function with the container. Because the order most usefull
>> for comparing between two instances doesn't need to be the most usefull
>> order in finding an element from a container.
>
> No, it wouldn't. Order relationships are a property of the type, not
> the container. The order relationships are right where they belong -
> attached to the type.

Order relationships are only a property of the type in a particular
sense. There certainly is not a one on one relationship between
order relationships and types. A type can have multiple order relationships
all usefull in different circumstances. If a specific order is
only usefull in the context of a spefic container I see no problem
with associating the order with the container.

> That notwithstanding, it's often practical to be
> able to override the order function for some specific method (and
> would be even if the order function were associated with the container
> instead of the type), so some of the methods that use order allow you
> to provide a function to use for them. If you really want a container
> type that has an order function associated with it, you can write
> one. If you want it made part of the language, you'll have to provide
> a use case.

Fair enough. Take the heapqueue module. The times that I had need
for a heapqueue this module was useless to me. The reason always
boiled down to the fact that the order defined on the object
(as far as there was one) was not the order in which I wanted
the objects processed. e.g. I want a heapqueue of sets that gives
priority according to the number of elements in the set. Or I have
two heapqueues each of intervals. The first gives priority according
to the low value, the second gives priority according the the high
value.

>> algorithm on a container of them, but such an order is in general
>> less usefull than the superset ordering when you are manipulating
>> sets.
>
> And you're free to implement a subclass of sets that does that.

But that is not usefull to me. Take sets. It's been a while so
I'm not sure I can dig it back up, but I once had an algorithm
manipulating sets, where this manipulation would involve the
normal superset order. This algorithm had two charateristics.

1) Manipulating certain sets, made the manipulation of other
   sets unnecessary.

2) Manipulating smaller sets was faster than manipulating
   larger sets.

3) Sets were constantly added and removed from the manipulating
   pool.

These characteristics made this a natuaral candidate for a heapqueue
that used the number of elements as (inverse) priority.

However the manipulation of a single set needed the normal
superset relationship as order relation.

So making a subclass of sets with an order usefull for the
heapqueue would only be a marginal improvement to the
existing situation.

> If you
> want to argue that the builtin sets should do that, you can - but
> that's unrelated to the question of how the comparison operators
> behave for the rest of the bulitin types.

What I argue is that there is no single order for a specific type.
There can be an order that is most usefull in general but which order
is usefull at a specific point depends on the context. Sometimes
this context is the container that the types belongs to, like
a heapqueue. Associating that order with the container seems to
most natural to treat this kind of circumstances.

-- 
Antoon Pardon