David Skelly wrote:
part of the reason for using enums is to constrain the range of values
It is indeed. But I think C# strikes the right balance; another reason for using enums is that it provides a more readable alternative to hard-coded ints and a more efficient alternative to string literals. C# does not allow implicit casts to enum values, precisely because it is unsafe. There is no run-time check when explicitly casting because it would introduce significant overhead. I find it rather too strict if Java as you claim does not allow casting to enum types from integer types. Imagine you have a class with many fields that each have a small predefined set of legal values. We can define enums to represent these sets, use byte as the base value, and store such data in a database using one byte per attribute. Storing the names is extremely inefficient: Each column has to be sized according to the maximum length permitted in the set of values. You'd easily go to 20 characters in many cases, and sometimes more, which depending on encoding will require 20 to 40 bytes of storage space. If you have five such fields, you could end up using 200 bytes instead of 5. And large row size == bad performance. If you can't cast to enum values, you'd have to write switches instead (switch (value) { case 1: return CreditCard.MasterCard; break; ...}) which is pretty boring work!
