Can enum be added to dynamically

[apm]

Can an enum start empty and be added to on the fly?

[Peter van der Goes]

"apm" <Co*********@Ad sorptionProcess Modeling.com> wrote in message
news:wWe2f.9538 $U%5.5934@laker ead05...

Can an enum start empty and be added to on the fly?

AFAIK, no.

[Daniel O'Connell [C# MVP]]

"apm" <Co*********@Ad sorptionProcess Modeling.com> wrote in message
news:wWe2f.9538 $U%5.5934@laker ead05...

Can an enum start empty and be added to on the fly?

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.

[Jeff Louie]

Well maybe your own enum can:

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.WriteLi ne(MyEnum.OPENE D.ToString());
Console.WriteLi ne(MyEnum.OPENE D.ToOrdinal().T oString());
Console.WriteLi ne(MyEnum.INVAL ID.ToString());
Console.WriteLi ne(MyEnum.INVAL ID.ToOrdinal(). ToString());
Console.WriteLi ne(MyEnum.CLOSE D.ToString());
Console.WriteLi ne(MyEnum.CLOSE D.ToOrdinal().T oString());
Console.ReadLin e();
}
}

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[Mike Schilling]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..

"apm" <Co*********@Ad sorptionProcess Modeling.com> wrote in message
news:wWe2f.9538 $U%5.5934@laker ead05...

Can an enum start empty and be added to on the fly?

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.

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 "deserializ ed" (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.)

[Daniel O'Connell [C# MVP]]

"Mike Schilling" <ms************ *@hotmail.com> wrote in message
news:uK******** ******@TK2MSFTN GP14.phx.gbl...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..

"apm" <Co*********@Ad sorptionProcess Modeling.com> wrote in message
news:wWe2f.9538 $U%5.5934@laker ead05...

Can an enum start empty and be added to on the fly?

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.

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 "deserializ ed" (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(whic h 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]

"Daniel O'Connell > 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.

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]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

"Mike Schilling" <ms************ *@hotmail.com> wrote in message
news:uK******** ******@TK2MSFTN GP14.phx.gbl...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..

"apm" <Co*********@Ad sorptionProcess Modeling.com> wrote in message
news:wWe2f.9538 $U%5.5934@laker ead05...
Can an enum start empty and be added to on the fly?

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.

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 "deserializ ed" (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(whic h 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.

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 [C# MVP]]

"apm" <Co*********@Ad sorptionProcess Modeling.com> wrote in message
news:dGE2f.1222 0$U%5.8789@lake read05...

"Daniel O'Connell > 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.

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.

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?

[Daniel O'Connell [C# MVP]]

"Mike Schilling" <ms************ *@hotmail.com> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

"Mike Schilling" <ms************ *@hotmail.com> wrote in message
news:uK******** ******@TK2MSFTN GP14.phx.gbl...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..

"apm" <Co*********@Ad sorptionProcess Modeling.com> wrote in message
news:wWe2f.9538 $U%5.5934@laker ead05...
> Can an enum start empty and be added to on the fly?

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.

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 "deserializ ed" (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(whic h 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.

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.