Typesafe Enum Pattern

[Jon Skeet [C# MVP]]

Well, yes, this is object-oriented, but for some reason I just can't see
redefining a type so radically. It seems like redefining integer, or byte as
an object. IMHO, it would be better to add a new type.

Why though? When we've already got the concept of an enum, which is
just very limited, why not embrace the idea of making it properly OO?

I can understand the reluctance to some extent, because even after I
knew about Java enums, I hadn't realised quite how useful they'd be
until I started living with them for a while. It's one of those ideas
which takes a while to sink in. It's also one of those things I miss
intensely when I come back from Java to C#...

Still, now that Mads is on the C# team, maybe we'll see them in a
future release

 

[Jon Skeet [C# MVP]]

I'm not sure what you mean by that. I was just trying to explain that
an instance of an Enum acutally behaves like a value-type (Curiously
though, VS.NET shows "class" on the tooltip for "Enum" in code,
although it derives from ValueType).

Both Enum and ValueType are classes, in fact.

If you want to produce the same
functionality as Enums (or as close as you can get, but with custom
state and behavior) using the tools that are currently at your
disposal, then you'd be better off using a struct, not a class.

Not necessarily. If I have a rich enum with several data members, it's
cheaper to pass a reference by value than to pass all those members.
Just making the type immutable is fine, in the same way that string is.

I think this directly addresses the point of the OP. The author
claims to have written a class using the current framework, at least
so it seems, to extend the Enum type. I intended my reply to address
some of the concerns I would have if someone gave me this new class
and I had to use it in place of Enums.

I think a lot of the concerns are off-base though. Yes, you could make
mistakes like making the enums mutable without thinking things through,
but that's the kind of mistake that can be made in a lot of places. The
fundamental concept of having an enumerated set of values is completely
separate from whether the type should be a value type or a reference
type, IMO.

My mistake on the implicit part.

It's an advantage because Enum already exists as a primitive in the
framework, supplying that functionality. The point is that you can
code it in a class by using casting overloads however it's just more
work trying to reinvent the wheel, IMO.

Well, not really a primitive, but it certainly exists in the framework
as a first-class citizen.

However, .NET enums *don't* provide all the desired functionality, a
lot of the time. Many times you see switch statements handling enums,
where if you could embed the logic (or whatever the switch is doing)
within the enum as a polymorphic method, the code would be a lot
clearer. I don't see what's wrong with making the leap to that more OO
way of doing things, even without the runtime supporting it in a first-
class manner.

Of course it's easy, but it's just more work trying to reinvent the
wheel before you can extend its behavior.

I was listing all of the aspects of Enum that one would have to
reproduce if they wanted to extend its behavior using a class in the
current framework. The point being that Enum is a primitive Type that
already provides all of this functionality. My last point addresses
why I think this is important.

Enums provide a certain amount of functionality, yes - but a lot of the
time there's other functionality (particularly the ability to store
extra, rich data and to act polymorphically) which is much more
important to me than a lot of the functionality that enums *do*
provide.

Maybe I can make my POV clearer by asking you if you have a class
that you wrote in .NET that extends enums and that you use in place
of them? If not, that's my point exactly. If so, then I give up. I'm
easy

I haven't done much .NET coding in anger since discovering how useful
Java classes are - and not since seeing some reasonably elegant ways of
impersonating the design in C#. I can say that trying to produce
designs in .NET which mirror the equivalent Java enums by using a C#
enum and help classes has led to much nastier code in the C# side, in
my experience.

I'm not arguing that a more robust Enum type, as a primitive,
wouldn't be a welcomed addition. Again I'm just trying to address the
OP. Enums have that support now and I would expect the author's class
to have it as well before I used it in place of Enums.

That makes sense *if* you really need the FlagsAttribute in a
particular scenario - but it doesn't make sense to insist that the
support is present in cases where you're not going to use it anyway. I
very rarely use FlagsAttribute, myself.

Yet. But I don't think that addresses the OP The author wrote a
custom class using the current framework. If the author wishes to
extend their class for designer support they could do so, of course,
but personally I'd rather just use a simple Enum right now.

And that loses you a lot - that's what I'm saying. By insisting that
enums are "good enough" you lose a lot of powerful OO design
possibilities.

Ok, I don't insist that all of my other types have only one or two
pieces of data and very limited behavior, however I do insist that
they aren't framework primitives that address a particular,
compile-time need

I'm not sure I see your point.

Well, I never said that! My post wasn't against the idea of a
primitive Type that addresses your concerns, but instead it was
against the idea of creating an Enum-enhanced type using a class in
the current framework. After reading your article I can see how I
might benefit from it, however I do agree that if I had it and used
it, I could probably appreciate the idea more than I do now.

Why are you against the idea of enabling a pleasant design even in the
slightly limited form which is currently available? Yes, there are
times when the present enums are sufficient - but where they aren't, I
think it's highly commendable to strive for a more OO solution than to
settle for an enum and a helper class.

As for the lack of Type-safety in Enums I don't think it's any reason
to be concerned. They are value-types, so it's the value that is
important, not the Type.

I don't see why being a value type makes the type safety any less
important. It's just as inappropriate to use a FontStyle as if it were
a FileAccess as it would be to use a String as if it were a Socket.

 

[Steven Nagy]

I haven't done much .NET coding in anger since discovering how useful
Java classes are - and not since seeing some reasonably elegant ways of
impersonating the design in C#. I can say that trying to produce
designs in .NET which mirror the equivalent Java enums by using a C#
enum and help classes has led to much nastier code in the C# side, in
my experience.

So whats the actual current solution here?
Jon, you are obviously very passionate about improvements to the enum
in future releases, but my issues exist now. That's why I found my way
to the type-safe enum pattern to begin with. What do you think of this
pattern, or can you suggest a better way? My previous code snippet was
based on some examples I found in java. I want to make sure I do this
properly the first time, because I might actually be using them in my
DAL.

Also, imagine the very common scenario where you have a table in DB
with static values. Something like what I have specified above in
chess... ways that a game could be ended (WhiteWins, BlackWins, Draw).
Because these values are not going to change for the life of the
solution, I want to have these represented as an enum. Do you think
using the ts enum pattern is a reasonable approach to representing that
mode? I'm sure state pattern would be applicable somewhere as well, but
for now I'm not managing the game's state, just creating passable
values to represent that state. Is this the best approach?

Cheers,
SN

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Actually, the Java type-safe enum is similar to .Net enums. It is the older
Java implementation that is exposed only as a class, and is not type-safe.

The old Java enum pattern (Bloch style) is the same
as what is generated behind the scene for Java 1.5 enum
and it is very type safe.

You can say that it is even more type safe than C# enum's,
because you can not even explicit type cast it to an int.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I can understand the reluctance to some extent, because even after I
knew about Java enums, I hadn't realised quite how useful they'd be
until I started living with them for a while. It's one of those ideas
which takes a while to sink in. It's also one of those things I miss
intensely when I come back from Java to C#...

Still, now that Mads is on the C# team, maybe we'll see them in a
future release

Two words: backwards compatibility.

Changing enums could break a lot of code.

Arne

 

[Dave Sexton]

Hi Jon,

Both Enum and ValueType are classes, in fact.

True, but I was referring to what VS.NET shows. It seems to always shows "struct" for value-types instead of "class" in the
intellisense, except on Enum. Not really imporant, just something I noticed.

Not necessarily. If I have a rich enum with several data members, it's
cheaper to pass a reference by value than to pass all those members.
Just making the type immutable is fine, in the same way that string is.

Cheaper, yes, but then your Type doesn't necessarily replace Enum. I think if you are going to extend an Enum's behavior by
creating a custom Type then your Type should also preserve the in-memory behavior of Enum, otherwise you're not really replacing
Enum your just creating a class that encapsulates the functionality that you desire, with a chosen set of functionality that
parallels that of Enum. I see them as two distinct entities if you're not preserving all of the functionality provided by Enum, and
not a replacement.

I think a lot of the concerns are off-base though. Yes, you could make
mistakes like making the enums mutable without thinking things
through, but that's the kind of mistake that can be made in a lot of places.

But that mistake won't be made if you aren't trying to reproduce functionality that is already provided to you by a primitive Type.
If your propsed extension existed in the framework now then things would be different.

The fundamental concept of having an enumerated set of values is
completely separate from whether the type should be a value type or a
reference type, IMO.

I disagree. I believe how the Type behaves in memory is very important. Enums are always passed as a value, and therefore a
base-type that will replace it must do the same otherwise it's not really a replacement, IMO.

Well, not really a primitive, but it certainly exists in the framework
as a first-class citizen.

I'll take your word for it because I really don't know.

But maybe that's because the real primtives aren't base types like Enum. For instance, having TypeCode.Enum might not be very
useful, which is why it doesn't exist, but it doesn't mean that the framework doesn't provide "primtive" support for Enum at
runtime. After all, there is an "IsEnum" property on the Type class. I guess I'd have to define what "primitive support" actually
means in terms of the compiler and CLR, however I just can't do that because I'm really no expert on that subject

(The point is that it's provided, intrinsically. Whether or not it's deemed as a true "primitive" doesn't affect my point.)

However, .NET enums *don't* provide all the desired functionality, a
lot of the time. Many times you see switch statements handling enums,
where if you could embed the logic (or whatever the switch is doing)
within the enum as a polymorphic method, the code would be a lot
clearer. I don't see what's wrong with making the leap to that more OO
way of doing things, even without the runtime supporting it in a
first- class manner.

But in the current framework your describing something that would no longer be an Enum. You're describing a class that provides
more functionality than Enum provides. I'm not against that in any way, and would recommend it over using custom Attributes on an
Enum, for example. If there was a base type, such as the one you've proposed, I'm sure I'd use it in places where it was
appropriate. I'm sure there would be an equal number of, if not more, places where Enum would still be appropriate. Not every Enum
requires additional behavior or state (I assume that most wouldn't benefit from that ability at all). Therefore, Enum doesn't need
to be completely replaced as Steven suggested in his OP.

Enums provide a certain amount of functionality, yes - but a lot of
the time there's other functionality (particularly the ability to
store extra, rich data and to act polymorphically) which is much more
important to me than a lot of the functionality that enums *do*
provide.

I agree that there may be times where you need more than what Enum provides while trading off existing functionality provided by
Enum because it's not needed. If your propsed extension existed now, then it would no longer be a custom Type, it would be
primitive (or first-class citizen . Steven's example is a custom Type and definately does not replace the Enum Type. They are
two different animals as I see it.

I haven't done much .NET coding in anger since discovering how useful
Java classes are - and not since seeing some reasonably elegant ways
of impersonating the design in C#. I can say that trying to produce
designs in .NET which mirror the equivalent Java enums by using a C#
enum and help classes has led to much nastier code in the C# side, in
my experience.

I have to admit you're making me sad saying that C# is nastier than Java. We're not going to lose you in the community any time
soon, I hope? .
I'm not a Java programmer so I can't concur - I'll just have to take your word on that.

My point was that you really can't (or shouldn't rather) replace Enum.

That makes sense *if* you really need the FlagsAttribute in a
particular scenario - but it doesn't make sense to insist that the
support is present in cases where you're not going to use it anyway. I
very rarely use FlagsAttribute, myself.

I completely agree. Again, Steven asked why he should use standard Enums at all. FlagsAttribute, IMO, was a good reason to use
Enums since they already provide that support. If he needs more than what Enum has to offer, he really doesn't have much of a
choice but to create a custom class now, but it's not going to replace Enum.

And that loses you a lot - that's what I'm saying. By insisting that
enums are "good enough" you lose a lot of powerful OO design
possibilities.

But just like your saying that FlagsAttribute isn't always necessary, I think OO Enums aren't always necessary either. I'm
perfectly content with the TypeCode Enum, for instance, as it stands in the current framework now. What more state or behavior
could be extended to TypeCode? What about FileAccess or BindingFlags for example? If you were to add any additional state or
behavior on these Enums it seems to me that the classes that actually use these enums and encapsulate the functionality associated
with them would then share functionality with another Type in the framework, breaking encapsulation.

I'm not sure I see your point.

I understood your question as meaning, "Why shouldn't the Enum type be able to store state information if your custom types can? On
the contrary, are your custom types limited in the amount of data they hold just like Enum is?"

My answer is simply that my classes aren't trying to provide the functionality that the Enum type does right now, and that Enum does
provide its functionality with the limitations that are present in the current framework. My types, therefore, cannot be compared
like this to the Enum class because they provide a different set of functionality that does require holding a variable amount of
state. It's like comparing apples and oranges, as I see it.

Why are you against the idea of enabling a pleasant design even in the
slightly limited form which is currently available? Yes, there are
times when the present enums are sufficient - but where they aren't, I
think it's highly commendable to strive for a more OO solution than to
settle for an enum and a helper class.

I'm actually for it. I read your article, as I stated, to help clear things up about the pattern as well. What I'm against is
trying to replace Enum type using a custom type in the current framework. I believe that's what this thread is about and I've tried
to prove why I think enum is useful. Sure, Steven can rewrite the functionality he needs from Enum everytime he needs to addorn it
with additional state or behavior, but he's by no means replacing the Enum type by doing so.

I don't see why being a value type makes the type safety any less
important. It's just as inappropriate to use a FontStyle as if it were
a FileAccess as it would be to use a String as if it were a Socket.

FontStyle style = FontStyle.Bold; // BTW, FlagsAttribute
FileAccess fa = (FileAccess) style;

I think it's a bit rediculous to assume that the lack of type-safety in Enum is at fault for code like the above. Sure, if it was
completely type-safe then you couldn't do that but a developer could just as easily use a static Parse method instead if they are
going to explicitly cast one type to another anyway. And if you pass around FontStyle as Int32 instead, and eventually cast it into
FileAccess then you're just asking for trouble. If you have an Enum value, pass it around and use it as an Enum and it will be
type-safe. Enum's are type-safe in every other aspect since the compiler will ensure that method parameters of a particular type of
Enum, for example, may only be passed instances of that Type (and at least it requires an explicit cast otherwise).

The reason why Enum being a value type is very important is because in some cases you may only have the "value" and not the "Type",
from say an unmanaged program for example. From a web service method perhaps, or maybe from a parsed flat-file. In these cases
it's the value that's important and this design becomes more like a "feature" than a "bug" It's nice to be able to explicitly
cast an int into an Enum value instead of calling some parse method (or not being able to at all in a poorly written class that
implements the pattern you speak of).

And anyway, I use Enum.IsDefined / InvalidEnumArgumentException in properties that set an Enum value and methods that accept an Enum
argument, unless of course the Enum is [Flags] or I can be certain by flow of control that my program will never supply anything but
an appropriate value.


Overall, I was trying to address Steven's question, "And it got me to thinking... why should I EVER use standard enums?"
- Because you may only need a subset or exactly what Enum provides, but no more. I think Enum is much more general-purpose and
common than the pattern that you have brought to our attention.

As a side note, a state machine would work well if you needed to relate several additional constants to one enum value and/or add
behavior that is dependant on each constant, but the pattern that Steve used in his example works just fine too. I don't recommend
using custom Attributes on Enum constants to provide this functionality, however, and I've seen some talk about that in this thread.
That seems like a bad idea to me.

 

[Jon Skeet [C# MVP]]

So whats the actual current solution here?
Jon, you are obviously very passionate about improvements to the enum
in future releases, but my issues exist now. That's why I found my way
to the type-safe enum pattern to begin with. What do you think of this
pattern, or can you suggest a better way? My previous code snippet was
based on some examples I found in java. I want to make sure I do this
properly the first time, because I might actually be using them in my
DAL.

The best implementation I've seen is the one in the comments for my
blog:

public abstract class ArithmeticOperation
{
private ArithmeticOperation()
{
}

public abstract int Eval(int x, int y);

public static readonly ArithmeticOperation Addition = new Add();

private class Add : ArithmeticOperation
{
public override int Eval(int x, int y)
{
return x + y;
}
}

public static readonly ArithmeticOperation Multiplication =
new Multiply();

// ...
}

This uses the fact that nested classes can use private constructors.
The only big downside of this is that you can't use the values in a
switch statement - and that it's a bit ugly, having to declare the
value separately from the class.

Also, imagine the very common scenario where you have a table in DB
with static values. Something like what I have specified above in
chess... ways that a game could be ended (WhiteWins, BlackWins, Draw).
Because these values are not going to change for the life of the
solution, I want to have these represented as an enum. Do you think
using the ts enum pattern is a reasonable approach to representing that
mode? I'm sure state pattern would be applicable somewhere as well, but
for now I'm not managing the game's state, just creating passable
values to represent that state. Is this the best approach?

I would always first consider whether you can do everything you need
with a "simple" enum. If you can't, the pattern above seems pretty
reasonable to me.

 

[Jon Skeet [C# MVP]]

Two words: backwards compatibility.

Changing enums could break a lot of code.

Oh, they couldn't just change what the "enum" keyword means. That's why
my blog post suggests using "class enum" to declare one

 

[Jon Skeet [C# MVP]]

Cheaper, yes, but then your Type doesn't necessarily replace Enum. I
think if you are going to extend an Enum's behavior by creating a
custom Type then your Type should also preserve the in-memory
behavior of Enum, otherwise you're not really replacing Enum your
just creating a class that encapsulates the functionality that you
desire, with a chosen set of functionality that parallels that of
Enum. I see them as two distinct entities if you're not preserving
all of the functionality provided by Enum, and not a replacement.

What real functionality of enum would you be missing? Note that
although I've always described the rich enum using classes, I don't
think there'd be anything to stop you from using a struct instead if
you wanted to.

But that mistake won't be made if you aren't trying to reproduce
functionality that is already provided to you by a primitive Type. If
your propsed extension existed in the framework now then things would
be different.

I'm still not sure where you're going, I'm afraid. The richer
functionality would allow you to semantically do everything the current
enum does. As Arne pointed out, in fact we'd need to keep the existing
enum anyway, but even if we'd originally had rich enums, I don't think
there's anything you could do with the current enums that you wouldn't
be able to do.

I disagree. I believe how the Type behaves in memory is very
important. Enums are always passed as a value, and therefore a
base-type that will replace it must do the same otherwise it's not
really a replacement, IMO.

Where do you see the difference between passing an immutable reference
type reference and passing an immutable value type value? I mean in
terms of what you can and can't usefully do, rather than strictly in
terms of implementation details.

I'll take your word for it because I really don't know.

From the docs for Type.IsPrimitiveImpl:

<quote>
The primitive types are Boolean, Byte, SByte, Int16, UInt16, Int32,
UInt32, Int64, UInt64, Char, Double, and Single.

But maybe that's because the real primtives aren't base types like
Enum. For instance, having TypeCode.Enum might not be very useful,
which is why it doesn't exist, but it doesn't mean that the framework
doesn't provide "primtive" support for Enum at runtime. After all,
there is an "IsEnum" property on the Type class. I guess I'd have to
define what "primitive support" actually means in terms of the
compiler and CLR, however I just can't do that because I'm really no
expert on that subject

(The point is that it's provided, intrinsically. Whether or not it's
deemed as a true "primitive" doesn't affect my point.)

That's fine, and how I understood you

But in the current framework your describing something that would no
longer be an Enum. You're describing a class that provides more
functionality than Enum provides. I'm not against that in any way,
and would recommend it over using custom Attributes on an Enum, for
example. If there was a base type, such as the one you've proposed,
I'm sure I'd use it in places where it was appropriate. I'm sure
there would be an equal number of, if not more, places where Enum
would still be appropriate. Not every Enum requires additional
behavior or state (I assume that most wouldn't benefit from that
ability at all). Therefore, Enum doesn't need to be completely
replaced as Steven suggested in his OP.

Well, at this point Enum *can't* be completely replaced - but I don't
see why we couldn't have syntax which would allow current enum
functionality with rich enums, particularly if you allowed "struct
enum" as well as "class enum".

I agree that there may be times where you need more than what Enum
provides while trading off existing functionality provided by Enum
because it's not needed. If your propsed extension existed now, then
it would no longer be a custom Type, it would be primitive (or
first-class citizen . Steven's example is a custom Type and
definately does not replace the Enum Type. They are two different
animals as I see it.

Quite possibly - but I don't think that makes it wrong of foolish for
Steven to use the same pattern, even though he needs some code of his
own.

I have to admit you're making me sad saying that C# is nastier than
Java. We're not going to lose you in the community any time soon, I
hope? . I'm not a Java programmer so I can't concur - I'll just
have to take your word on that.

Oh C# is a nicer language *in general*, but there are times I prefer
Java - with rich enums leading the way. Likewise C# generics beat Java
generics for most things, but having co/contravariance can be handy
sometimes.

My point was that you really can't (or shouldn't rather) replace Enum.

Can't in the real world, certainly. Shouldn't (in an ideal world where
we were having this discussion before .NET ever came out) depends on
whether the replacement could actually cover everything that enum
currently does.

I completely agree. Again, Steven asked why he should use standard
Enums at all. FlagsAttribute, IMO, was a good reason to use Enums
since they already provide that support. If he needs more than what
Enum has to offer, he really doesn't have much of a choice but to
create a custom class now, but it's not going to replace Enum.
Right.


But just like your saying that FlagsAttribute isn't always necessary,
I think OO Enums aren't always necessary either. I'm perfectly
content with the TypeCode Enum, for instance, as it stands in the
current framework now. What more state or behavior could be extended
to TypeCode? What about FileAccess or BindingFlags for example? If
you were to add any additional state or behavior on these Enums it
seems to me that the classes that actually use these enums and
encapsulate the functionality associated with them would then share
functionality with another Type in the framework, breaking
encapsulation.

Yes, I wouldn't suggest removing the existing enums - although some of
them *may* benefit from added behaviour, even now.

I understood your question as meaning, "Why shouldn't the Enum type
be able to store state information if your custom types can? On the
contrary, are your custom types limited in the amount of data they
hold just like Enum is?"

My answer is simply that my classes aren't trying to provide the
functionality that the Enum type does right now, and that Enum does
provide its functionality with the limitations that are present in
the current framework. My types, therefore, cannot be compared like
this to the Enum class because they provide a different set of
functionality that does require holding a variable amount of state.
It's like comparing apples and oranges, as I see it.

My point was that fundamentally, in principle, I don't see why enums
should be as limited as they are currently. Just because C has such
limited enums doesn't mean we should be content with that state of
affairs now.

I'm actually for it. I read your article, as I stated, to help clear
things up about the pattern as well. What I'm against is trying to
replace Enum type using a custom type in the current framework. I
believe that's what this thread is about and I've tried to prove why
I think enum is useful. Sure, Steven can rewrite the functionality he
needs from Enum everytime he needs to addorn it with additional state
or behavior, but he's by no means replacing the Enum type by doing
so.

He's replacing a number of uses for the Enum type, I guess. I suspect
we've been talking largely at cross-purposes...

FontStyle style = FontStyle.Bold; // BTW, FlagsAttribute
FileAccess fa = (FileAccess) style;

I think it's a bit rediculous to assume that the lack of type-safety
in Enum is at fault for code like the above.

I don't see why not - if they were any other type you wouldn't be able
to do it, including other value types.

Sure, if it was completely type-safe then you couldn't do that but a
developer could just as easily use a static Parse method instead if
they are going to explicitly cast one type to another anyway.

And if they want to convert from one enum to another, that would be a
good way of doing it. (Easier with rich enums, admittedly...) Why allow
conversions that shouldn't be available?

And if you pass around FontStyle as Int32 instead, and eventually
cast it into FileAccess then you're just asking for trouble. If you
have an Enum value, pass it around and use it as an Enum and it will
be type-safe. Enum's are type-safe in every other aspect since the
compiler will ensure that method parameters of a particular type of
Enum, for example, may only be passed instances of that Type (and at
least it requires an explicit cast otherwise).

They don't ensure that the values are actually within the enumerated
set though. You could do:

FileAccess fa = (FileAccess) 123;

Now, I suspect that 123 isn't a valid value for FileAccess - so I don't
think that should be allowed. Of course, prohibiting it would stop
FlagsAttribute from working, so you'd need something like the Java
EnumSet instead, which could internally use a representation like that
anyway.

The reason why Enum being a value type is very important is because
in some cases you may only have the "value" and not the "Type", from
say an unmanaged program for example. From a web service method
perhaps, or maybe from a parsed flat-file. In these cases it's the
value that's important and this design becomes more like a "feature"
than a "bug" It's nice to be able to explicitly cast an int into
an Enum value instead of calling some parse method (or not being able
to at all in a poorly written class that implements the pattern you
speak of).

So provide a user-defined conversion when you need to. Personally I
prefer to pass the name around than the integral value - it's more
descriptive. Either way, you can do it in situations you need it.

And anyway, I use Enum.IsDefined / InvalidEnumArgumentException in
properties that set an Enum value and methods that accept an Enum
argument, unless of course the Enum is [Flags] or I can be certain by
flow of control that my program will never supply anything but an
appropriate value.

Do you like having to do that everywhere though? Sounds like a bit of a
pain to me.

Overall, I was trying to address Steven's question, "And it got me to
thinking... why should I EVER use standard enums?" - Because you may
only need a subset or exactly what Enum provides, but no more. I
think Enum is much more general-purpose and common than the pattern
that you have brought to our attention.

And that's entirely reasonable. I think I'd misunderstood you.

As a side note, a state machine would work well if you needed to
relate several additional constants to one enum value and/or add
behavior that is dependant on each constant, but the pattern that
Steve used in his example works just fine too. I don't recommend
using custom Attributes on Enum constants to provide this
functionality, however, and I've seen some talk about that in this
thread. That seems like a bad idea to me.

Attributes can *occasionally* be useful like that, but I agree they're
not a good general purpose mechanism for this.

 

[Kevin Spencer]

Hi Jon,

I have no problems either way. This has undoubtedly been a good discussion
of the issues.
--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com

A watched clock never boils.

 

[Dave Sexton]

Hi Jon,

What real functionality of enum would you be missing? Note that
although I've always described the rich enum using classes, I don't
think there'd be anything to stop you from using a struct instead if
you wanted to.

The functionality that is missing is obvious if you look at the code posted by Steven. His type is a class, doesn't handle
FlagsAttribute, doesn't implement IComparable or IConvertible, won't return true if you call Type.IsEnum, etc. It definately
couldn't replace Enum as is. Without a base type to handle the "class enum" aspect of things, he'd be plucking out functionality
from Enum that he'd like to include each time in a new class. That's why I shun at calling his or another's shot at this pattern in
the current framework Enum or an extension thereof. To me it's just an entirely different entity that uses an enum-type pattern,
but definately doesn't replace Enum -- and that's ok!

After all, Steven could create his own struct that provides almost the same functionality as Int32 except throws an error when -2 is
assigned and returns a nicely formatted ToString value. It doesn't replace Int32, however.

I'm still not sure where you're going, I'm afraid. The richer
functionality would allow you to semantically do everything the current
enum does. As Arne pointed out, in fact we'd need to keep the existing
enum anyway, but even if we'd originally had rich enums, I don't think
there's anything you could do with the current enums that you wouldn't
be able to do.

Actually, I was agreeing with that idea exactly. I just wanted to make the point that one could make those mistakes if one had to
keep recoding the same functionality for enums over and over again just to conform to a desired pattern that Enum doesn't provide
alone. A base Type as you suggested would help to prevent those unwanted mistakes. For now, it's just a pattern without a type and
that could present problems when coding different implementations between classes trying to address the same issues with Enum.

If this pattern is common enough I would love to see a base Type in a subsequent version of the framework. Unfortunately, as you
correclty suggested, I really don't have experience using the pattern and so I cannot accurately judge it's usefulness as a
framework Type.

Where do you see the difference between passing an immutable reference
type reference and passing an immutable value type value? I mean in
terms of what you can and can't usefully do, rather than strictly in
terms of implementation details.

I don't see a difference in terms of useability. They both provide the same functionality to the system.

I think the concept of a value-type applies to Enum more than a reference type does and so does it apply to the pattern, in general.
Obviously choosing between one or the other is important when implementing a base Type. It will directly affect the Type's
useability in hash tables since in a struct you should always provide your own implementation of GetHashCode, for instance, and more
importantly it will change the way the CLR manages the Type's memory. Both points are extremely important when considering the
Type's use in operations that require a high level of performance and scalability.

You've already stated reasons why using a struct instead of your "class" enum proposal wouldn't necessarily be correct, and I do
agree with that because it really is a "class" enum which does extend the behavior of Enum considerably. However, I don't think
it's completely unreasonable to have a need for the same set of functionality on top of a struct, citing the reasons that I just
mentioned above.

From the docs for Type.IsPrimitiveImpl:

<quote>
The primitive types are Boolean, Byte, SByte, Int16, UInt16, Int32,
UInt32, Int64, UInt64, Char, Double, and Single.
</quote>

I never actually doubted you

That's fine, and how I understood you

Great! Hopefully we can start chopping off some of these other large paragraphs too because I can't seem to find my scroll box
anymore

Well, at this point Enum *can't* be completely replaced - but I don't
see why we couldn't have syntax which would allow current enum
functionality with rich enums, particularly if you allowed "struct
enum" as well as "class enum".

Sounds good to me.

Quite possibly - but I don't think that makes it wrong of foolish for
Steven to use the same pattern, even though he needs some code of his
own.

I don't think it makes him foolish at all either. If the framework doesn't provide a base Type for him to use then he has to make
due with what he's got. But it still won't replace Enum.

Oh C# is a nicer language *in general*, but there are times I prefer
Java - with rich enums leading the way. Likewise C# generics beat Java
generics for most things, but having co/contravariance can be handy
sometimes.

I'm sure you already have an article on that... or at least on covariance and contravariance. Care to post the link so we can read
up?

Can't in the real world, certainly. Shouldn't (in an ideal world where
we were having this discussion before .NET ever came out) depends on
whether the replacement could actually cover everything that enum
currently does.

I like that fact that enums weren't replaced in .NET with a more robust implementation. It's a simple type meant to due simple
things and it does them well. Encapsulation at its finest, IMO. Your proposed extensions could live happily along side of Enums.
Reasons might exist even to use an Enum inside your "class enum".

Yes, I wouldn't suggest removing the existing enums - although some of
them *may* benefit from added behaviour, even now.

Some, definately. SocketError enum comes to mind. I'd love a programmatically-accessible description straight from the source that
could be displayed to the end-user. As a matter of fact, I bet a lot of Enums would benefit from descriptive fields for each
constant.

My point was that fundamentally, in principle, I don't see why enums
should be as limited as they are currently. Just because C has such
limited enums doesn't mean we should be content with that state of
affairs now.

(BTW when I wrote "On the contrary" I really meant "In other words". I just wrote the wrong phrase without thinking)

I can agree with that POV. I don't think your example illustrated that at all though.

Was the C enum the basis for limiting the functionality of enums in .NET? Was there never any proposal for additional extensions
such as yours before .NET 1.0 was RTM?

He's replacing a number of uses for the Enum type, I guess. I suspect
we've been talking largely at cross-purposes...

I guess so. I was continuously trying to address the two questions from the OP. It sounded to me like Steven was looking for an
argument for the use of the Enum pattern in the current framework as opposed to just using a custom implementation everywhere. I'm
sure I've side-stepped a bit now, however, but I've tried to stay on-point as much as possible.

The 6th point in my OP was debatable against your opposing point of view. I stated that (and asked for evidence) because I've never
used this pattern. From your article, our early discussions and Steven's code example, it became clear to me that the pattern was
indeed useful. I think the source of much confusion was that I changed gears really early on just for that one point. IIRC I
stated that my POV changed a couple of times, though. Looking back, it seems like you and Steven thought that the whole point of my
OP was #6, when in fact it really wasn't. #6 was to debate the pattern only and it wasn't intended to address the questions in the
OP in any way.

Either way, we're covering some interesting topics, IMO.

I don't see why not - if they were any other type you wouldn't be able
to do it, including other value types.

Ok, I'm blaming bad code like that on the developer that wrote it and not the framework that allowed it

I agree that it would be nice if the compiler didn't allow it, however. Why does it even allow that conversion in the first place?
I completely understand Int32 to Enum : int, as I've already stated, but I really have no idea why A : Enum to B : Enum is allowed
at all. I can't think of any time in the past that I've ever actually done something like that on purpose. I wonder if that
behavior is just a side-effect of the intrinsic ability to cast from Enum to Enum and the way the CLR handles derived Types.
Perhaps it just treats derived Enums as Enums and nothing more. I don't see any operator overloads in Reflector for the Enum type
or derived Enum types.

And if they want to convert from one enum to another, that would be a
good way of doing it. (Easier with rich enums, admittedly...) Why allow
conversions that shouldn't be available?

I'll agree with that.

They don't ensure that the values are actually within the enumerated
set though. You could do:

FileAccess fa = (FileAccess) 123;

Now, I suspect that 123 isn't a valid value for FileAccess - so I don't
think that should be allowed. Of course, prohibiting it would stop
FlagsAttribute from working, so you'd need something like the Java
EnumSet instead, which could internally use a representation like that
anyway.

Right. In order to have FlagsAttribute on Enum that functionality is required. So, why is the base Type in .NET that represents
flags, Enum with an Attribute? Maybe they should have seperated the two into distinct Types:

enum E { A, B }
flags F { F0, F1, F2, F4, F8 } // automatic binary sequencing would have been nice, if I can call it that

So provide a user-defined conversion when you need to. Personally I
prefer to pass the name around than the integral value - it's more
descriptive. Either way, you can do it in situations you need it.

User-defined conversion of what? The framework allows an explicit conversion from the base Type to the Enum's Type. Useful when
you only have the integral value, which does happen from time to time, especially when dealing with data from an external system
that you are normalizing into your own through the use of an Enum (common in Interop, in my experience). If I were to derive a type
from your "class enum" I wouldn't expect that built-in coversion to exist already like it does in Enum. I think Enum is special in
that aspect since it can successfully accomplish the cast through CLR support without the need for custom code. As for the other
allowed conversions, I could argue against them too.

I too prefer to serialize an Enum's string representation, for instance, but it's just not always possible due to constraints of the
data model and possibly performance concerns.

And anyway, I use Enum.IsDefined / InvalidEnumArgumentException in
properties that set an Enum value and methods that accept an Enum
argument, unless of course the Enum is [Flags] or I can be certain by
flow of control that my program will never supply anything but an
appropriate value.

Do you like having to do that everywhere though? Sounds like a bit of a
pain to me.

Yea, it's not fun But we all have things that we dislike about the framework. That one isn't on the top of my list, however,
especially because it's quite rare that it's required. You really only need to do that check when writing public library code that
uses Enums. (Admittedly, I do it internally as well just to aid in debugging, just like Assert)

Attributes can *occasionally* be useful like that, but I agree they're
not a good general purpose mechanism for this.

Yea, I guess if you have a constant value to associate it with and you're already using reflection or don't mind losing out on the
benefits of an OO approach, and performance isn't a concern, and neither is type-saftey, and you can ensure a certain level of trust
(I guess full trust would be required?) when your program runs.

If you said, "Hardly ever", I might agree!

 

[Steven Nagy]

Hi Jon and Kevin,

I have no problems either way. This has undoubtedly been a good discussion
of the issues.

Yes it has and has given me a lot to work with.
Thankyou both for your constructive input.

Cheers,
Steven

 

[Jon Skeet [C# MVP]]

The functionality that is missing is obvious if you look at the code
posted by Steven.

I think the problem is with the assumption that the original code
posted is the ultimate pattern. It's a start, and no doubt it handles
what Steven wants it to handle, but I'm sure we could do better if we
had a larger set of goals to start with.

I think we've largely agreed on most of the rest of the things in your
message, hence the snippage. Now, I'm not sure whether or not I've got
the time to do this exercise properly, but if we agree on the feature
set that we'd want from a rich enum, we could work out:

1) A pattern or base class to use without any CLR/framework/compiler
support.

2) What could be done with extra support, and from what. (For instance,
switching elegantly would requite extra compiler support, I suspect.)

Are you interested?

 

[Dave Sexton]

Hi Jon,

I think the problem is with the assumption that the original code
posted is the ultimate pattern. It's a start, and no doubt it handles
what Steven wants it to handle, but I'm sure we could do better if we
had a larger set of goals to start with.

Agreed. My perspective was in-line with Steven's requirements since he started the thread and it was his code snippet. We seem to
have expanded the thread into finding answers to questions that apply to a more general usage of the pattern, but it has proven to
be useful in identifying more requirements to be addressed by your proposed "class enum" type, which seems to address Steven's needs
too.

I think we've largely agreed on most of the rest of the things in your
message, hence the snippage. Now, I'm not sure whether or not I've got
the time to do this exercise properly, but if we agree on the feature
set that we'd want from a rich enum, we could work out:

1) A pattern or base class to use without any CLR/framework/compiler
support.

(I assume you want to target 2.0)

2) What could be done with extra support, and from what. (For instance,
switching elegantly would requite extra compiler support, I suspect.)

Are you interested?

I'm interested in the result, and I'd be more than happy to help out in the design in any way I could. You definately have a lot
more experience than me on this topic, given your background in Java at least, so I'm not sure how much more I could add. I'd like
to try if you think I can help. I'm great at annoying people by playing devil's advocate - that's for sure.

As long as there aren't any stringent time constraints on the project I'd be happy to participate.

I'm not sure how you want to collaborate. Feel free to email me if you'd like, or respond to this post. When I get a chance I'll
take a more thorough look at your article on the subject. If you've started a list of the features you'd like to include just link
me to it. If you'd like me to start one or add to yours let me know.

Also, do you know of any other articles to which you could post a link that describes the pattern from a different perspective or in
more detail? (I hope everyone feels free to reply to this question)

(Curiously, no mention of the pattern exists on http://patternshare.org, nor does it exist on Microsoft's Patterns and Practices for
..NET Version 1.1.0 (http://msdn.microsoft.com/library/d...us/dnpatterns/html/EspPattlets.asp?frame=true).)

--

Another concern I have about the pattern is its relationship to the state machine pattern. The state pattern seems to address the
needs of a developer that would use the class-enum pattern in a more robust way by expanding the pattern out into multiple types.
It will also scale better, it seems. I guess in order for the class-enum pattern to be useful it really shouldn't overlap with
either the Enum or State pattern, but find a place somewhere in between. Some overlap with both Enum and the state pattern is to be
expected.

Here are a few points off the top of my head that I think should be addressed when desiging the pattern's base class (some of which
may turn out to not have any real bearing, but they just seem important enough to mention):

1. Language agnostic (may be consumed by any CLS-compliant language)
2. Performance related to Enum and state pattern. Ideally, I think it should perform better than state pattern in its general use
but not necessarily better than Enum.
3. Scalability in terms of the capability to scale up, increasing the number of constants defined in a derived class, and to scale
out, nesting references to instances of classes derived from the same pattern base (and related ease-of-use compared to the state
pattern when the number needs to grow very high, in which case I think the state pattern might just be a better choice, but that
remains to be seen.)
4. Memory consumption. Find places where the amount of memory consumed by the pattern, in general, can be reduced. Especially in a
base class.
5. Extensibility and flexibility (i.e. Can a derived class override certain methods or otherwise extend the behavior of the class
outside of its intended, general useage scenerios?)
6. GC and related IDisposable issues of the base class and the object instances that a derived class may composite.

Thanks for the discussion. It's been interesting, to say the least.

 

[Steven Nagy]

The functionality that is missing is obvious if you look at the code

I think the problem is with the assumption that the original code
posted is the ultimate pattern. It's a start, and no doubt it handles
what Steven wants it to handle, but I'm sure we could do better if we
had a larger set of goals to start with.

The code I posted was only a small set and designed to illustrate where
I was going with my implementation of the typesafe enum pattern. The
class actually includes a lot more static methods for moving external
decision making steps into the class itself. It is the intention that
if the decision making steps around the enum are incorporated into the
enum object itself, then it becomes easy to scale that enum with
additional values without needing to find every reference in code and
changing it.

The downside is that I find myself halfway to a State implementation,
as mentioned by yourselves. If you guys were to find a happy medium, it
would certainly assist my situation. But finding a way to as
consistantly as possible include the decision making process into the
class-enum itself would be extremely handy. I haven't found a great way
of doing this yet, and am open to suggestions.

1) A pattern or base class to use without any CLR/framework/compiler
support.

I'm a fair bit less knowledgable about pattern construction then you
two.
Does this statement mean that you want the pattern to be platform
independent?
Or that in a .NET context, it doesn't require usage of namespaces such
as Reflection?

Are you interested?

Yes, but I am sure the question was not directed at me.
So I would be just as happy with an outcome.

SN