Enumeration idioms: Values from different enumerations

[Ben Sizer]

Antoon Pardon wrote:
> Op 2005-12-16, Ben Sizer schreef <kylotan at gmail.com>:
> > Is it possible to make it have the following sort of behaviour? :
> >
> >>>> ShirtSize.small == AppleSize.small
> > True
> >>>> ShirtSize.small is AppleSize.small
> > False
> >
> > It works for comparing a boolean (True) vs. an integer (1), so it has
> > some sort of precedent. (Especially if you make the tenuous assumption
> > that True,False are language-supported 'enums' for 0 and 1.)
>
> I'm against it. I don't like the following returning True:
>
>   ShirtSize.small in [ShirtSize.Medium, AppleSize.small]

I agree to an extent. I can see that being unwanted behaviour, although
not really a big one, and no worse than in C++. I think that when you
have a list of alternatives like that, they're either hard-coded by
selectively picking from the enumeration's initialisation list, or by
being generated according to some other criteria. Either way, it would
be hard to end up with the wrong type of value into that list, I think.

> I also think it may cause problems with other comparisons.
>
> Supose the following:
>
>   col = Enum('red', 'green', 'blue')
>   paint = Enum('violet' , 'blue', 'red')
>
> Then we get the following situation:
>
>   col.red == paint.red and col.blue == paint.blue
>
> but
>
>   col.red < col.blue and paint.blue < paint.red

I don't think that's a problem - does any other language make any
guarantees on ordering across multiple enumerations? Transitivity
within any single enumeration plus transivity of equivalence across
multiple enumerations, should be enough for most needs, no?

-- 
Ben Sizer