AFAIK, no.
I'll make it definative. No.
What are you trying to do? Chances are there is another pattern to pull it
off since enums that are modified at runtime really don't make a whole lot
of sense.
sealed class MyEnum
{
private String name;
private static int nextOrdinal= 1;
private int ordinal= nextOrdinal++;
private MyEnum(String name)
{
this.name= name;
}
public override String ToString()
{
return name;
}
public int ToOrdinal()
{
return ordinal;
}
public static MyEnum INVALID= new MyEnum("Invalid"); // ordinal 1
public static MyEnum OPENED= new MyEnum("Opened"); // ordinal 2
public static MyEnum CLOSED=new MyEnum("Closed"); // ordinal 3
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
//
// TODO: Add code to start application here
//
Console.WriteLine(MyEnum.OPENED.ToString());
Console.WriteLine(MyEnum.OPENED.ToOrdinal().ToString());
Console.WriteLine(MyEnum.INVALID.ToString());
Console.WriteLine(MyEnum.INVALID.ToOrdinal().ToString());
Console.WriteLine(MyEnum.CLOSED.ToString());
Console.WriteLine(MyEnum.CLOSED.ToOrdinal().ToString());
Console.ReadLine();
}
}
Regards,
Jeff
*** Sent via Developersdex http://www.developersdex.com ***
Sure they do.
Picture this: a distributed application, in which the messages sent between
processes include enums. It's possible for machine A running version 1.0 to
communicate with machine B running 2.0. It's also possible that new values
were added to enums in newer version.
So, A receives a message from B containing an enum value it wasn't compiled
with. It would be nice if A could represent it as a value of the enum that
wasn't present at compilation time, and update the enum's internal
structures so that GetNames(), GetValue(), etc. process it correctly. That
way, if the message is "deserialized" (using the term loosely) into an
object, the cases of known and unknown enum value can be treated alike (i.e.
in both cases the object has a field whose type is the enum.)
It's possible (not even hard) to build something similar to an enum that can
do this, but it would be nice if enums had this ability built in. (By the
way, it turns out to be handy to be able to distinguish compile-time from
dynamic enum values. For example, if you're building a list for users to
pick values from, you often want to restrict it to compile-time values.)
I never really considered enums more than a language nicety. They have a
modicum of use outside of that, I suppose, but a dictionary works just as
well when working with widely dynamic values.
Even if you take a larger view of enums, I don't think it really makes sense
to add it. As you pointed out, being able to distinguish between compile
time, static enums(what we use every day) and dynamic enums(which as you
pointed out is easy to write) is nessecery, so why try to merge the two and
complicate the whole system to add functionality that would take 10 minutes
of work to write yourself, especially when it offers no language level
advantages(which is why enums pass, they are simple, language level
additions, this would be a runtime addition). Adding a class to handle this
situation would be acceptable, but they just don't make sense in enums.
I'm want to give the user a set of choices that will present themselves as
an enumeration in intellisence. It would be easier to write the code if the
values of the enum could be read from a file. I suppose a macro can be
written to help write the code.
Becasue enums nicely do 90% of what I want, and it would be nicer to reuse
and extend that functionality rather than have to duplicate it. You know,
what OOP is supposed to be good at :-)
Enums, atleast the .NET version, are pretty bad OOP IMHO. No inheritance, no
polymorphism, just flat value with a type.
Intellisense is a compile time thing, built entirely on static code
knowledge. It doesn't make sense to change things at runtime and expect them
to change at compile time as well. Are you trying to generate code files?
Indeed - bring on the Java enumerations! (They have a few wrinkles, but
generally they're incredibly handy.)
--
Jon Skeet - <sk...@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
I have to agree, I'm starting to like some of the advantages more and more.
Although I don't think traditional inheritance is going to happen within the
.NET framework(changing enums from value types to reference types is a huge
change), allowing method definitions, including a basic set of operations
like IsSet(), Set(), and Unset() for [Flags] enums, would certainly help
alot. Some form of enum composition might not be a bad idea either.
Come again? I don't really know what you are trying to achieve, let alone
waht you mean here.
Can't add to those dynamically either (At least in any supported way. I
haven't tried to hack into the $VALUES array.)
No, you can't add to them - but they stil have fabulous advantages
compared with .NET enums.