bearophile Wrote: > Jason House: > > > IMHO, enum is a patchwork collection of features... manifest constants, > > enumerated lists, and bitmasks are all conflated into something rather > > ugly.< > > Manifest constants defined with enum look a little ugly, and I too don't like > it, but it's not even a syntax problem, it's a naming problem, so we can > survive with it. Do you have ideas for alternative design of manifest > constants? (LDC may even not need manifest constants at all, especially when > you use link-time optimization). > > The enumerated lists of D2 may enjoy to grow some built-in way to invert > them, and little more. > > Regarding bitmasks, I don't like how they are implemented in C#. D can do > better, while keeping things simple. > > Do you have ideas for a better design of those three things? (I don't want > heavy Java-like enums). > > Bye, > bearophile
Manifest constants reflect a toolchain problem and *not* a naming problem. They exist only because the linker isn't smart enough to optimize immutable variables. LLVM should already have this implemented. regarding Java style enumarations, I disagree that they are too heavy. They are a *much* better design than the C/D/.. design. I think the C style use of enums to implement bit masks is the problem and not the enum itself. there are two better designs IMO: a) low level where you need manual control of the bit patterns - use ubyte/etc directly is more explicit andf therfore better. b) you don't care about the bits themselves and only want to implement OptionA | OptionB efficiently - bit patterns should *not* be exposed and should be encapsulated by a type. Java has a enumSet (I don't remember the exact name) that handles that efficently for you. either way, you shouldn't ever provide an interface for Option flags where the underlining implementation - the bit values are exposed to the user.
