A
apm
Can an enum start empty and be added to on the fly?
apm said:Can an enum start empty and be added to on the fly?
apm said:Can an enum start empty and be added to on the fly?
Daniel O'Connell said: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.
Mike Schilling said: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.)
off since enums that are modified at runtime really don't make a whole lot
of sense.
Daniel O'Connell said: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.
apm said:"Daniel O'Connell > What are you trying to do? Chances are there is
another pattern to pull it
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.
Mike Schilling said: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![]()
Daniel O'Connell said:Enums, atleast the .NET version, are pretty bad OOP IMHO. No inheritance, no
polymorphism, just flat value with a type.
Jon Skeet said:Indeed - bring on the Java enumerations! (They have a few wrinkles, but
generally they're incredibly handy.)
I think that is the only option with .NET. COM seems so much moreDaniel O'Connell said: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?
apm said:I think that is the only option with .NET. COM seems so much more
powerful than .NET.
Jon Skeet said:Indeed - bring on the Java enumerations! (They have a few wrinkles, but
generally they're incredibly handy.)
Mike Schilling said:Can't add to those dynamically either (At least in any supported way. I
haven't tried to hack into the $VALUES array.)