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*********@AdsorptionProcessModeling.com> wrote in message
news:wWe2f.9538$U%5.5934@lakeread05...

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

AFAIK, no.

[Daniel O'Connell [C# MVP]]

"apm" <Co*********@AdsorptionProcessModeling.com> wrote in message
news:wWe2f.9538$U%5.5934@lakeread05...

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.WriteLine(MyEnum.OPENED.ToString());
Console.WriteLine(MyEnum.OPENED.ToOrdinal().ToStri ng());
Console.WriteLine(MyEnum.INVALID.ToString());
Console.WriteLine(MyEnum.INVALID.ToOrdinal().ToStr ing());
Console.WriteLine(MyEnum.CLOSED.ToString());
Console.WriteLine(MyEnum.CLOSED.ToOrdinal().ToStri ng());
Console.ReadLine();
}
}

Regards,
Jeff

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

[Mike Schilling]

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

"apm" <Co*********@AdsorptionProcessModeling.com> wrote in message
news:wWe2f.9538$U%5.5934@lakeread05...

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 "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.)

[Daniel O'Connell [C# MVP]]

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

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

"apm" <Co*********@AdsorptionProcessModeling.com> wrote in message
news:wWe2f.9538$U%5.5934@lakeread05...

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 "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.

[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****************@TK2MSFTNGP12.phx.gbl...

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

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

"apm" <Co*********@AdsorptionProcessModeling.com> wrote in message
news:wWe2f.9538$U%5.5934@lakeread05...
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 "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.

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*********@AdsorptionProcessModeling.com> wrote in message
news:dGE2f.12220$U%5.8789@lakeread05...

"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****************@tk2msftngp13.phx.gbl...

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

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

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

"apm" <Co*********@AdsorptionProcessModeling.com> wrote in message
news:wWe2f.9538$U%5.5934@lakeread05...
> 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 "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.

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.

[Jon Skeet [C# MVP]]

Daniel O'Connell [C# MVP] <[e-mail]> wrote:

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.

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

[Daniel O'Connell [C# MVP]]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Daniel O'Connell [C# MVP] <[e-mail]> wrote:

> 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.

Indeed - bring on the Java enumerations! (They have a few wrinkles, but
generally they're incredibly handy.)

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.

[apm]

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

"apm" <Co*********@AdsorptionProcessModeling.com> wrote in message
news:dGE2f.12220$U%5.8789@lakeread05...

"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?

I think that is the only option with .NET. COM seems so much more
powerful than .NET.

[Daniel O'Connell [C# MVP]]

"apm" <Co*********@AdsorptionProcessModeling.com> wrote in message
news:lUP2f.12607$U%5.2339@lakeread05...

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

"apm" <Co*********@AdsorptionProcessModeling.com> wrote in message
news:dGE2f.12220$U%5.8789@lakeread05...

"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?

I think that is the only option with .NET. COM seems so much more
powerful than .NET.

Come again? I don't really know what you are trying to achieve, let alone
waht you mean here.

[Mike Schilling]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Daniel O'Connell [C# MVP] <[e-mail]> wrote:

> 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.

Indeed - bring on the Java enumerations! (They have a few wrinkles, but
generally they're incredibly handy.)

Can't add to those dynamically either (At least in any supported way. I
haven't tried to hack into the $VALUES array.)

[Jon Skeet [C# MVP]]

Mike Schilling <ms*************@hotmail.com> wrote:

Indeed - bring on the Java enumerations! (They have a few wrinkles, but
generally they're incredibly handy.)

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.

--
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