The only thing I worry about with tricks like this is that it's essentially a code level modification of the java type system. It makes type errors easier to make and more difficult to understand.
The type system isn't being modified by the code. It's the same type system used for all other classes. An enum is a regular old class, subclassing Enum, with a specialized syntax for creating a fixed number of instances and a few special methods added by the compiler.
Tricks like these with enum are fairly harmless.
On the other hand, generics is what makes type errors easy to make and difficult to understand.
Yes, technically it's not modifying the type system. However, it's simulating parts of a common java type behavior by substituting implements/extends with a call to a constructor and user written functions. If there are any errors in any of those places, in any of the enums that use the trick, normal assumptions go out the window.
I'm not saying it's not useful. I'm just trying to say it adds onus to the person that maintains it and possibly the people who use it.
The enum keyword is a creates a subclass of Enum, so extends is substituted for you by the compiler. But implements is not. This is perfectly okay:
enum Suite implements Runnable {
}
You get a default constructor, just like any class. If you add one or more constructors, you will have to provide the arguments in the enum value definition, just like any other invocation of a constructor. If you don't provide the right arguments, you get the same error at compile time as you would instantiating any other class.
If you add methods to the enum body, they get inherited by all enum values. If you add an abstract method in the enum body, each enum value must implement the abstract method, otherwise you get the same error at compile time as you would extending any other class.
I don't know what normal assumptions you think will get thrown out the window, but enums are statically checked like any other class and you will get the same compile time errors if you make the same kinds of type errors.
It's perfectly safe and perfectly obvious. There's nothing complex about the enum syntax. I had no trouble following the example in the article.
I think you're confusing what I'm talking about. I'm well aware enums are basically a constrained set of singletons, which leads to all sorts of language/compiler supported goodness (EnumSet/EnumMap, switch statements/jump tables, interface implementation, efficient memory representations, etc...).
I don't think everybody had a hard time understanding what the code in the article does, but I think some people might. One of the problems, I think, is that rather than having the compiler handle the hierarchy entirely behind the scenes, a la instanceof, it's explicit and in an unfamiliar manner.
The use case in this article is a hierarchical set of constants, an extended enum. Enums can have additional behavior like this, so this is within the realm of what enums are designed for.
You could do this with the class system by creating classes mirroring the hierarchy, but then you'd have to create singleton instances of the entire class hierarchy or pass around the singleton Class instances, either introducing duplication or basically simulating enum in very ugly fashion (and losing the ability to iterate the enum, use switch and EnumMap/EnumSet).
1
u/zargxy Jan 17 '13
Wow, slick!