On Friday, February 22, 2013 9:07:32 AM UTC-8, Andrew Barnert wrote:
On Feb 21, 2013, at 15:24, Greg Ewing <greg....@canterbury.ac.nz> wrote:
> That sounds reasonable. However, I'm wondering if there isn't a
> third case: where you don't care about the values, but you do
> want them to have a defined ordering?

This is a valid point.  I think there are a lot of cases where enums are useful without any ordering, but there are arguably some cases where order would be useful (the immediate example that comes to mind is "logging levels", where DEBUG, INFO, and ERROR don't necessarily need to have any numerical meaning, but it would be nice to be able to say that DEBUG < INFO < ERROR)..  I think it should be possible to build this into an existing enum implementation which doesn't inherently rely on underlying numbers, though..  I'll look into it..

And a fourth case: You don't care about the values, but you want to be able to | them together into a set.

Heh.. I was kinda hoping nobody was going to bring this up yet :)  Good point, though, and FWIW, I had considered this too but didn't bring it up initially because I was afraid it would muddy the discussion too much too early.   I do however agree that this is a use case that will ultimately be important to support, and it's been in the back of my mind.  This actually applies both to the "valueless" case and the "valued" case, but in somewhat different ways.

As you mentioned, in the "valueless" case, the most obvious way to deal with this is with sets.  I think we could probably ameliorate the single-value case a bit by just having enum objects also behave like single-item sets if used with set operations (which I don't think is too magic), and then we can define the '|' operator to just create (or add to) an enum-set..

The valued case is actually more complicated, because ideally if READ = enum(1) and SHARED = enum(4), then saying "READ | SHARED" should produce something that has an int() value of the or'd values (5), but it would also be nice if it still represented itself symbolically (as "READ | SHARED", for example, instead of "5"), and though not strictly required, it would probably also be nice if they could be inspected using the same set-type operations as valueless enums/sets ("if READ in openmode", for example).  This would probably require some sort of new "enum-set" class/type which supported amalgomated valued enums, but I think it would still be doable without too much magic (I hope).  Then of course there's extra issues like: if we also support string-enums, what does 'or' mean for string constants? (etc, etc..)

But in summary, I think the valueless case is actually pretty easy to implement, but doing it well with valued-enums is much more work, which once again reinforces my opinion that valueless enums are useful to have, and preferable to use when lowlevel-type-compatibility is not explicitly required by some API..

--Alex