OK, so I lied; I’m not stopping at 5 parts.
I’ve been working with enumerations frequently lately; the Battle.net chat protocol is binary and therefore the values that come over the wire have different contextual meanings based on the values that might have preceded them. For example, a chat message event actually can have about a dozen meanings; it can be a server-broadcasted message, a message from another user, or just an announcement that a user joined the channel. In addition to the standard values identifying things like message type, messages typically have one form or another of flags; if the event is based on a user, the flags contain information about the user’s status on the server (whether the user is an administrator or has operator privileges in the channel). Others, such as channel information updates, contain information about the chat channel itself, such as whether it is public, silent, or otherwise normal.
Having had to deal with enumerations frequently has made me hate code like this:
Especially when working with bitwise values (enumerations decorated with the [Flags] attribute), because of the specific operator precedence constraints that C# places on the developer, this becomes annoying quickly. So much so, that classes where I have to do that frequently end up with several TestFlag() methods, but even these are limited. Consider code like this:
In proposition 1 we have to implement n methods, either repeatedly or in a globally-defined, internal utility class; that stinks. Proposition 2 is difficult to implement; we can’t place a type constraint because C# doesn’t allow enum type constraints, and since enums have a type constraint themselves of always being an integral value, this would be ideal; but type constraints in this case are limited to struct, which doesn’t guarantee operator | or operator &. In proposition 3, every time we want to test, we need to cast to int (or long) and lose type information. I guess that works, but then you worry that you end up with code like this:
No, there’s a cleaner solution, and, like the compiler features added to C# 3.0, it doesn’t require a new CLR: automatic properties on enumerations.
Internally, enumerations are treated as their base numeric type by the CLR; the variable itself carries around type information, but it’s not strong and can be changed by direct casting. But the compiler always knows the type of a local variable and can apply it directly. So, consider applying a property to an enumeration variable called IsEnumField. Consider this [Flags] enumeration, and look at the code that uses it when using this style of coding:
We can easily identify the pattern that the compiler supports; prefix "Is" to the field name and perform the underlying logic.
The great part about this solution is that the emitted code is exactly the same as what you or I would produce right now. So the compiler can know by its clever compiler tricks to do this:
In that example, I qualified the type name UserFlags nine times. Can you say "carpal tunnel"?
There are some considerations to make about this. First, there are already going to be some enumerations in the wild with field names that begin with "Is," and it could very easily raise confusion if someone sees code such as user.Flags.IsIsOnline. Fortunately, the solution is equally simple: create a decorator attribute, just like we did for extension methods:
Then, when you create an enumeration that you’d like to expose these style of properties, simply decorate the enumeration with this attribute. IntelliSense knows to show the properties, the compiler knows to translate the properties, and we’re in the free and clear.
Wouldn’t it be great?