enum question

[codymanix]

why do I always have to write the name of the enum type in front of the enum
member?

why not simply writing Red instead of Color.Red? The compiler always knows
which type is expected so there cannot be a collision and the compiler can
simply look up the enum member in the expected type.

wouldn't that be easier and simpler? I see not technical reason for that
verbose syntax.
In c++, writing the type is also not neccesary, so why is it in c#?

cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

 

[Daniel O'Connell]

why do I always have to write the name of the enum type in front of the enum
member?

why not simply writing Red instead of Color.Red? The compiler always knows
which type is expected so there cannot be a collision and the compiler can
simply look up the enum member in the expected type.

wouldn't that be easier and simpler? I see not technical reason for that
verbose syntax.
In c++, writing the type is also not neccesary, so why is it in c#?

For the sake of simpliicty and standardization. No other thing in C# works
like that, everything outside of locals uses an object reference(either an
implicit this or an explicit one). Adding non-typed enums would break that
mold. It also makes it unclear what exactly "Red" is. Removing the current
functionality would, in the end, probably reduce simplicity. Globals are
bad, promoting members in a given type to the global level is worse. The
rules governing type resolution are complicated enough, adding implicit
resolution based on type is certainly NOT needed.

I keep reiterating this, and people don't seem to get it. C# is NOT C++, and
bringing in every feature in C++ is a bad idea. This is a feature I do not
think is particularly appealing in C++, let alone C#. If you want to use
that syntax, MC++ is fully open to you.

cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

 

[Rob Teixeira [MVP]]

I'd like to add to the post that this is precisely what Intellisense is for

Though I do have to admit that VB's intellisense is a bit more responsive in
this scenario.
The intellisense keeps you from having to type lots of extra characters, and
in the end, the code is more explicit.

-Rob Teixeira [MVP]

why do I always have to write the name of the enum type in front of the enum
member?

why not simply writing Red instead of Color.Red? The compiler always knows
which type is expected so there cannot be a collision and the compiler can
simply look up the enum member in the expected type.

wouldn't that be easier and simpler? I see not technical reason for that
verbose syntax.
In c++, writing the type is also not neccesary, so why is it in c#?

For the sake of simpliicty and standardization. No other thing in C# works
like that, everything outside of locals uses an object reference(either an
implicit this or an explicit one). Adding non-typed enums would break that
mold. It also makes it unclear what exactly "Red" is. Removing the current
functionality would, in the end, probably reduce simplicity. Globals are
bad, promoting members in a given type to the global level is worse. The
rules governing type resolution are complicated enough, adding implicit
resolution based on type is certainly NOT needed.

I keep reiterating this, and people don't seem to get it. C# is NOT C++, and
bringing in every feature in C++ is a bad idea. This is a feature I do not
think is particularly appealing in C++, let alone C#. If you want to use
that syntax, MC++ is fully open to you.

cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

 

[Frank Rizzo]

For the sake of simpliicty and standardization. No other thing in C# works
like that, everything outside of locals uses an object reference(either an
implicit this or an explicit one). Adding non-typed enums would break that
mold. It also makes it unclear what exactly "Red" is. Removing the current
functionality would, in the end, probably reduce simplicity. Globals are
bad, promoting members in a given type to the global level is worse. The
rules governing type resolution are complicated enough, adding implicit
resolution based on type is certainly NOT needed.

I keep reiterating this, and people don't seem to get it. C# is NOT C++, and
bringing in every feature in C++ is a bad idea. This is a feature I do not
think is particularly appealing in C++, let alone C#. If you want to use
that syntax, MC++ is fully open to you.

Yes, and I think people get what you are saying. The point that you are
missing is that languages are designed to used by *people* who write
code. So it seems to me that the compiler team could have forsaken one
religious argument in favor of language usability.

I easily find this to be the most annoying feature of the language.

And it is not only C++ that had it handy. So did VB6.

 

[Frank Oquendo]

I see not technical reason for that verbose syntax.

public enum Color
{
White = 0;
Red;
Blue
};

public enum Alarm
{
Red = 0;
Amber;
Green
};

int num = (int) Red;

So is num equal to 1 or 0?

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

 

[Frank Oquendo]

The compiler always knows which type is expected

BTW, where'd you get this idea? An enum can be one of many of primitive
types. What happens when I try to stuff the value of a float enum into a
byte?

In addition, I recall quite clearly that my C++ enums had tell-tale
prefixes in order to make their use clear. Seems to me that many of us
were already qualifying our enums. We just didn't have to type a dot to
do it.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

 

[Daniel O'Connell]

Yes, and I think people get what you are saying. The point that you are
missing is that languages are designed to used by *people* who write
code. So it seems to me that the compiler team could have forsaken one
religious argument in favor of language usability.

I easily find this to be the most annoying feature of the language.

And it is not only C++ that had it handy. So did VB6.

Personally, I consider this "feature" to be a VERY annoying and nasty
feature of any language. I find that it reduces code readbility and ease of
maintence. Even in MC++ I prefix my enums. I'll even go so far as to say the
C++ :: syntax is a bit clearer than the universal . as far as readability,
but unqualified enums are not.

 

[Daniel O'Connell]

public enum Color
{
White = 0;
Red;
Blue
};

public enum Alarm
{
Red = 0;
Amber;
Green
};

int num = (int) Red;

So is num equal to 1 or 0?

In this case, the compiler would have to issue an error and require you
specify which enum you are using. Its more troubling in cases like

int Red = 45;

int num = (int)Red;

Its likely the resolution rules would elect to use locals over enum's
promoted to the global level, meaning that is a bug the compiler couldn't
help you with, assuming of course you wanted an enum.

 

[Dan Brussee]

public enum Color
{
White = 0;
Red;
Blue
};

public enum Alarm
{
Red = 0;
Amber;
Green
};

int num = (int) Red;

So is num equal to 1 or 0?

If Im not mistaken, the question has to do with items that are already
defined as of a particular enum "type". If I had a method called

public bool CheckAlarm(Alarm whichone) {
............
}

and I called it with

bool answer = CheckAlarm(Alarm.Green);

then why would it be so difficult for the compiler to figure out what
this means?

bool answer = CheckAlarm(Green);

 

[Frank Oquendo]

public bool CheckAlarm(Alarm whichone) {
...........
}

and I called it with

bool answer = CheckAlarm(Alarm.Green);

then why would it be so difficult for the compiler to figure out what
this means?

bool answer = CheckAlarm(Green);

That still doesn't cover situations where the type is not declared:

MyAlarm.Code = (Alarm) 1;
int num = (int) Red;

Rather than have rules for "special situations", what we have is
uniformity which enhances readability and maintainability.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

 

[codymanix]

I see not technical reason for that verbose syntax.

public enum Color
{
White = 0;
Red;
Blue
};

public enum Alarm
{
Red = 0;
Amber;
Green
};

int num = (int) Red;

So is num equal to 1 or 0?

The compiler must reject that. In this case you have to be explicit, since
the compiler cannot guess the desired type:

int num = (int)Color.Red;

But in all other cases the desired type is well known by the compiler why am
I forced to explicitly state it?

- for instance members in a class I can omit the "this"-keyword since in
most cases it is not needed and just annoying.
- for static class members I can omit the classname when in the same class.
- you can omit the "private" keyword

so why can't I omit the enum name?

 

[codymanix]

wouldn't that be easier and simpler? I see not technical reason for that

For the sake of simpliicty and standardization. No other thing in C# works
like that, everything outside of locals uses an object reference(either an
implicit this or an explicit one). Adding non-typed enums would break that
mold. It also makes it unclear what exactly "Red" is. Removing the current
functionality would, in the end, probably reduce simplicity. Globals are
bad, promoting members in a given type to the global level is worse. The
rules governing type resolution are complicated enough, adding implicit
resolution based on type is certainly NOT needed.

I keep reiterating this, and people don't seem to get it. C# is NOT C++, and
bringing in every feature in C++ is a bad idea. This is a feature I do not
think is particularly appealing in C++, let alone C#. If you want to use
that syntax, MC++ is fully open to you.

In the newest java version they introduced a feature named static import.
that means if you write "import Java.AWT.Color" for example,
you can use the color enum without explicit stating the type. they surely
had reasons for that.

 

[Dan Brussee]

That still doesn't cover situations where the type is not declared:

MyAlarm.Code = (Alarm) 1;
int num = (int) Red;

Rather than have rules for "special situations", what we have is
uniformity which enhances readability and maintainability.

Hate to difer with you, but I see this as the same as using namespace
aliases, etc. If you want me to always type in Alarm.Red the why not
always make me type in System.Web.Blah.Blah.Blah too? It would
certainly make things more readable, woudnt it? I dont want that to
sound nasty, but I dont really see that much of a difference.

 

[Daniel O'Connell]

The compiler must reject that. In this case you have to be explicit, since
the compiler cannot guess the desired type:

int num = (int)Color.Red;

But in all other cases the desired type is well known by the compiler why am
I forced to explicitly state it?

- for instance members in a class I can omit the "this"-keyword since in
most cases it is not needed and just annoying.
- for static class members I can omit the classname when in the same class.
- you can omit the "private" keyword

so why can't I omit the enum name?

Because your not in the enum type, you are in another type referencing the
enum.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

 

[Daniel O'Connell]

In the newest java version they introduced a feature named static import.
that means if you write "import Java.AWT.Color" for example,
you can use the color enum without explicit stating the type. they surely
had reasons for that.

VB supports this as well(for static members anyway). I'm not saying no one
uses it, I just think its a horrid construct. And, I reiterate, not every
feature you find in another language needs to be in this one, especially
ones that make the language uglier, more complex, harder to deal with. If I
wanted to use C++, I'd use C++.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

 

[Daniel O'Connell]

Hate to difer with you, but I see this as the same as using namespace
aliases, etc. If you want me to always type in Alarm.Red the why not
always make me type in System.Web.Blah.Blah.Blah too? It would
certainly make things more readable, woudnt it? I dont want that to
sound nasty, but I dont really see that much of a difference.

They provide a increase in speed, but thre is a minor difference. I would be
rather up in arms for a feature that allows you to not have to specify a
class name for static members either. It comes down to a balance. Having
random enum values in the global namespace is a very ugly situation, just as
if all static members were global. Would you think that is a good idea as
well?

 

[Dan Brussee]

They provide a increase in speed, but thre is a minor difference. I would be
rather up in arms for a feature that allows you to not have to specify a
class name for static members either. It comes down to a balance. Having
random enum values in the global namespace is a very ugly situation, just as
if all static members were global. Would you think that is a good idea as
well?

I agree with the balance thing. I just dont think that there is any
different level of balance in this area. The definition of the method
where the parameter being passed would define which enum set is
allowed.

I grant you that I would normally NOT use this syntax (without the
enum definition) if only for the sake of being able to get the list of
values via intellisense (there, I said it... I like intellisense!)

 

[Daniel O'Connell]

I agree with the balance thing. I just dont think that there is any
different level of balance in this area. The definition of the method
where the parameter being passed would define which enum set is
allowed.

I grant you that I would normally NOT use this syntax (without the
enum definition) if only for the sake of being able to get the list of
values via intellisense (there, I said it... I like intellisense!)

I'd prefer better intellisense overall. There is no reason(other than time
issues) that Color backColor = couldn't pop up a prompt for the Color enum,
it would allow easier reading AND easier typing, or at the least a set of
possible values in scope(including enum values) that could be assigned.
Ideally I'd like to see all methods that return Color, all properties and
fields of type Color and the members of Color in scope to be
displayed(usually this is just going to be the Color members), and if the
(int) type cast is applied, the whole list shoud be available as it is
today.
All in all, I like intellisense too, I just don't thinkg changing the
language is the proper solution, just make the intellisesne engine better,
it'll shorten typing quite a bit more anyway.

 

[Jon Skeet [C# MVP]]

why do I always have to write the name of the enum type in front of the enum
member?

why not simply writing Red instead of Color.Red? The compiler always knows
which type is expected so there cannot be a collision and the compiler can
simply look up the enum member in the expected type.

No, the compiler does *not* always know what type is expected. What if
you do:

object x = Red;

Does that mean Color.Red or SomethingElse.Red?

wouldn't that be easier and simpler? I see not technical reason for that
verbose syntax.

In C#, every expression has a type. There's no appropriate type for
"Red" is there - it could be Color or SomethingElse. This is a Bad
Thing in terms of language clarity, IMO.

 

[Frank Oquendo]

- for instance members in a class I can omit the "this"-keyword since
in most cases it is not needed and just annoying.

Agreed but that's because this notation implies you're dealing with an
instance.

- for static class members I can omit the classname when in the same
class.

This is bad practice. I had no idea C# would let you do such a thing.

- you can omit the "private" keyword

This is also bad practice as it not self-documenting in the least.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)