Wrong enum comparisons
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Mon May 28 12:21:14 PDT 2012
On 5/28/12 1:07 PM, foobar wrote:
> It depends on what exactly the general concept is, is this a predefined
> set of values or is it an ordered list. I'd argue that the set is more
> general and we shouldn't force an ordering when one isn't strictly
> required. Of course, the programmer should be able to add an ordering
> when it's required.
Ascribing ordinal values is not ordering.
> How to implement an order:
> IMO casts usually indicate code smell.
> I think something like Color.Red.ordinal states the intention much
> better than a cast.
Well ordinal could always be a function that does the cast...
> Could you please explain the issues you see in Java's Enum that cause
> you to reject such a design?
Too big for what it does. Not worth getting into details as I don't have
a strong opinion or one of much consequence.
At the end of the day, it is fairly clear to me that D's enum is in no
interesting point on the convenience/safety tradeoff scale, and doesn't
offer anything worth its presence in the language. It's just a bit less
broken than typedef, which was just egregious. No surprise there -
aspects of the language that received attention (e.g. floating point)
turned out well whereas those that didn't (either through incomplete
analysis or inheriting a bad design) turned out rather badly. I'd put
typedef (good thing it's gone), lazy, and enum in the latter category.
Andrei
More information about the Digitalmars-d
mailing list