Re: Typesafe Enum Pattern
- From: "Dave Sexton" <dave@jwa[remove.this]online.com>
- Date: Wed, 4 Oct 2006 17:33:44 -0400
Hi Jon,
"Jon Skeet [C# MVP]" <skeet@xxxxxxxxx> wrote in message news:MPG.1f8e20c694f1e5d98d512@xxxxxxxxxxxxxxxxxxxxxxx
Dave Sexton <dave@jwa[remove.this]online.com> wrote:
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.
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/default.asp?url=/library/en-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.
--
Dave Sexton
.
- References:
- Typesafe Enum Pattern
- From: Steven Nagy
- Re: Typesafe Enum Pattern
- From: Kevin Spencer
- Re: Typesafe Enum Pattern
- From: Steven Nagy
- Re: Typesafe Enum Pattern
- From: Dave Sexton
- Re: Typesafe Enum Pattern
- From: Jon Skeet [C# MVP]
- Re: Typesafe Enum Pattern
- From: Dave Sexton
- Re: Typesafe Enum Pattern
- From: Jon Skeet [C# MVP]
- Re: Typesafe Enum Pattern
- From: Dave Sexton
- Re: Typesafe Enum Pattern
- From: Jon Skeet [C# MVP]
- Re: Typesafe Enum Pattern
- From: Dave Sexton
- Re: Typesafe Enum Pattern
- From: Jon Skeet [C# MVP]
- Typesafe Enum Pattern
- Prev by Date: Timer Array in c#, VS2005
- Next by Date: Re: Converting Windows C# Application to a Windows NT Service
- Previous by thread: Re: Typesafe Enum Pattern
- Next by thread: Re: Typesafe Enum Pattern
- Index(es):
Relevant Pages
|