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]

"codymanix" <do*********************@gmx.de> wrote in message
news:Oo**************@TK2MSFTNGP12.phx.gbl...

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]

"Daniel O'Connell" <[e-mail]> wrote in message
news:OF*************@TK2MSFTNGP11.phx.gbl...

"codymanix" <do*********************@gmx.de> wrote in message
news:Oo**************@TK2MSFTNGP12.phx.gbl...

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]

Daniel O'Connell wrote:

"codymanix" <do*********************@gmx.de> wrote in message
news:Oo**************@TK2MSFTNGP12.phx.gbl...

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.

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]

codymanix wrote:

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]

codymanix wrote:

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]

"Frank Rizzo" <no****@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

Daniel O'Connell wrote:

"codymanix" <do*********************@gmx.de> wrote in message
news:Oo**************@TK2MSFTNGP12.phx.gbl...

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 knowswhich type is expected so there cannot be a collision and the compiler cansimply 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.

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]

"Frank Oquendo" <fr****@acadxpin.com> wrote in message
news:e%****************@TK2MSFTNGP10.phx.gbl...

codymanix wrote:

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?

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. --
There are 10 kinds of people. Those who understand binary and those who
don't.

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

[Dan Brussee]

On Sat, 27 Dec 2003 10:41:50 -0600, "Frank Oquendo"
<fr****@acadxpin.com> wrote:

codymanix wrote:

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?

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]

Dan Brussee wrote:

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?

--
cody

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

[Dan Brussee]

On Sat, 27 Dec 2003 13:56:37 -0600, "Frank Oquendo"
<fr****@acadxpin.com> wrote:

Dan Brussee wrote:

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.

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.

[codymanix]

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

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.

--
cody

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

[Daniel O'Connell]

"codymanix" <do*********************@gmx.de> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

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

"codymanix" <do*********************@gmx.de> wrote in message
news:uA**************@tk2msftngp13.phx.gbl...

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.

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]

"Dan Brussee" <db******@nc.rr.com> wrote in message
news:h7********************************@4ax.com...

On Sat, 27 Dec 2003 13:56:37 -0600, "Frank Oquendo"
<fr****@acadxpin.com> wrote:

Dan Brussee wrote:

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.

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]

On Sat, 27 Dec 2003 16:25:33 -0600, "Daniel O'Connell"
<[e-mail]> wrote:

"Dan Brussee" <db******@nc.rr.com> wrote in message
news:h7********************************@4ax.com.. .

On Sat, 27 Dec 2003 13:56:37 -0600, "Frank Oquendo"
<fr****@acadxpin.com> wrote:

>Dan Brussee wrote:
>
>> 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.

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?

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]

"Dan Brussee" <db******@nc.rr.com> wrote in message
news:97********************************@4ax.com...

On Sat, 27 Dec 2003 16:25:33 -0600, "Daniel O'Connell"
<[e-mail]> wrote:

"Dan Brussee" <db******@nc.rr.com> wrote in message
news:h7********************************@4ax.com.. .

On Sat, 27 Dec 2003 13:56:37 -0600, "Frank Oquendo"
<fr****@acadxpin.com> wrote:

>Dan Brussee wrote:
>
>> 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.

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 berather 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 asif 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!)

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

codymanix <do*********************@gmx.de> wrote:

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Frank Oquendo]

codymanix wrote:

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

[Frank Oquendo]

codymanix wrote:

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.

They wanted to make a bad thing worse, apparently.

I hate Java's method for enumerated values. So long as two static finals
are of the same type and value, you can freely swap one for the other.
That means there's nothing ensuring you're using the correct constants
except your own good manners.

Plus you have to wade through all the other static finals in a given
class which may or may not have anything to do with the method you're
calling.

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

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

[cody]

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

they should have better disallow name collisions between locals and instance
members.
assigning a local variable instead of the intended instance member is a very
common error,
it happens to me all the time!

class A
{
int i;
A(int i){ i=i; }
}

why not simply making a compiler error when such a collision occures?
private instance members from the base class can be ignored in this case.

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

Hm. Agreed. I think thats because if you refactor the method and change it
from static
to non-static or vice versa you don't have to change all the calls. but that
would be
only in its class, so not great deal.

- you can omit the "private" keyword

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

I find it stupid. why a private keyword at all? private is the default, and
all things
should be private when you don't explicity say otherwise.
So why "private"?? the keyword private looks too similar to public and
omitting it
would be imho far more readable and less typing!!!

--
cody

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

[Jon Skeet [C# MVP]]

Frank Oquendo <fr****@acadxpin.com> wrote:

- you can omit the "private" keyword

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

I disagree with this one, partly because it's easy to remember the
defaults in C# - the default access modifier for *anything* is the most
restrictive one. That also means that if you don't mean the default one
but omit it, you'll make it *more* restrictive rather than less. It
depends on who you work with though - if the people reading my code
were unlikely to know that the default member variable access is
private, I'd include it. Otherwise, I wouldn't.

I also disagree about the static member invocation business, personally
- but it's all personal opinion, really.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Frank Oquendo <fr****@acadxpin.com> wrote:

codymanix wrote:

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.

They wanted to make a bad thing worse, apparently.

I hate Java's method for enumerated values. So long as two static finals
are of the same type and value, you can freely swap one for the other.
That means there's nothing ensuring you're using the correct constants
except your own good manners.

Plus you have to wade through all the other static finals in a given
class which may or may not have anything to do with the method you're
calling.

When Java 1.5 comes in with the static imports, it'll have type-safe
enums in the language, so it won't be making a bad thing worse in that
sense.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[codymanix]

> object x = Red;

Does that mean Color.Red or SomethingElse.Red?

The compiler should reject that. You have to state the fully qualified name
here: Color.Red. But this scenario is not the common case, normally the
compiler knows which type is expected and the programmer can guess the type
from the context.

--
cody

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

[codymanix]

> > > - you can omit the "private" keyword

This is also bad practice as it not self-documenting in the least.
I disagree with this one, partly because it's easy to remember the
defaults in C# - the default access modifier for *anything* is the most
restrictive one. That also means that if you don't mean the default one
but omit it, you'll make it *more* restrictive rather than less.

Agreed!
It depends on who you work with though - if the people reading my code
were unlikely to know that the default member variable access is
private, I'd include it. Otherwise, I wouldn't.
Somebody who doesn't know the default acessibility level is not a
programmer,
especially it it is so easy as in c#.
in c++ and java things are a bit more complicated here. in c++ changing a
struct into
a class changes it default accessibility level so a private keyword was
needed. but in c#?
I also disagree about the static member invocation business, personally
Yes for generally use of it is a stupid feature. It would throw all static
methods in the
global namespace. But with enums it is a different thing because the type
depends on
the context, unintentionally using the wrong enum type cannot happen.
- but it's all personal opinion, really.

Not really. Some thing _are_ bad and some _are_ good. After programming lots
of
stuff and gaining more experience you know what is good and what is bad.

--
cody

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

[Jon Skeet [C# MVP]]

codymanix <do*********************@gmx.de> wrote:

object x = Red;

Does that mean Color.Red or SomethingElse.Red?

The compiler should reject that. You have to state the fully qualified name
here: Color.Red. But this scenario is not the common case, normally the
compiler knows which type is expected and the programmer can guess the type
from the context.

The compiler doesn't know, because it only evaluates each expression to
start with - and the expression "Red" doesn't have any type. It's as
much a language purism thing as anything else - but I personally
believe it adds readability too, especially when the enums are used as
method parameters (i.e. the type isn't actually visible in the same
line of code).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[codymanix]

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

I can tell you why. In c++, all enum members are, indeed part of the global
namespace. you cannot declare more than one enum member with the same name.

enum Color{ Red };
enum HairCoor {Red};

results in a compiletime error in c++. thats why c++ programmers often use
prefixes to avoid name collisions.

in c#, all enums provide its own "namespace". my suggestion was just to
provide the ability to omit the enum name because the desired type is known.

--
cody

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

[cody]

> > > object x = Red;

Does that mean Color.Red or SomethingElse.Red?

The compiler should reject that. You have to state the fully qualified name here: Color.Red. But this scenario is not the common case, normally the
compiler knows which type is expected and the programmer can guess the type from the context.

The compiler doesn't know, because it only evaluates each expression to
start with - and the expression "Red" doesn't have any type. It's as
much a language purism thing as anything else - but I personally
believe it adds readability too, especially when the enums are used as
method parameters (i.e. the type isn't actually visible in the same
line of code).

enum Color{Red };
enum Hairstyle {Red };

class Bar{
Color Color;
void Foo(Color c);
}

Bar bar = new Bar().;

bar.Foo(Red); // the compiler knows that Color is desired here and looks up
the member Red in Color.

bar.Color = Red; // the same here.

do you mean now what i mean? the expression is not evaluated as usual, the
type depends on the context.
that is a new paradigm but i find it good.

in .NET using the attribute classes allow a similar syntax:

[ThingyAttribute(Thingyness=VeryThingy)]
void Bar()
{
}

--
cody

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

[codymanix]

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

in c++ enum members are in a global namespace, but in c# they are not.
my proposal was just an automatic lookup of the correct type depending on
the context
so the enum name can be omitted in most cases.

--
cody

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

[Jon Skeet [C# MVP]]

cody <do*********************@gmx.de> wrote:

bar.Foo(Red); // the compiler knows that Color is desired here and looks up
the member Red in Color.
No, it really doesn't - because it doesn't see the whole statement
until it's parsed each expression, which must currently have a type.
The fact that each expression has a definite type is very useful when
it comes to defining the language in a relatively easy to understand
way. Your suggestion would throw that completely out of whack.
bar.Color = Red; // the same here.

do you mean now what i mean? the expression is not evaluated as usual, the
type depends on the context.

So the expression itself has no type, giving rise to the problem
above...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[codymanix]

> > bar.Foo(Red); // the compiler knows that Color is desired here and
looks up

the member Red in Color.

No, it really doesn't - because it doesn't see the whole statement
until it's parsed each expression, which must currently have a type.
The fact that each expression has a definite type is very useful when
it comes to defining the language in a relatively easy to understand
way. Your suggestion would throw that completely out of whack.

bar.Color = Red; // the same here.

do you mean now what i mean? the expression is not evaluated as usual, the type depends on the context.

So the expression itself has no type, giving rise to the problem
above...

Under normal circumstances there would be no problem as the compiler can
determine the exact type of the expression from the context.
however there would indeed be problems that could arise under certain
circumstances:

enum Color { Red }
enum Hair { Red }
void Foo (Hair h){}
void Foo (Color c){}

int num = (int) Red;

or

Foo(Red);

In both instances the compiler cannot know the type of the enum so it has to
be explicitly stated.

--
cody

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

[Jon Skeet [C# MVP]]

codymanix <do*********************@gmx.de> wrote:

Under normal circumstances there would be no problem as the compiler can
determine the exact type of the expression from the context.

Yes, but you still seem to have missed the point that it's a
fundamental change in the language philosophy when the type of the
expression requires context. The current language philosophy makes the
language easier to understand, IMO.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[codymanix]

> > Under normal circumstances there would be no problem as the compiler can

determine the exact type of the expression from the context.

Yes, but you still seem to have missed the point that it's a
fundamental change in the language philosophy when the type of the
expression requires context. The current language philosophy makes the
language easier to understand, IMO.

It was just an idea. Maybe in the future somebody will pick this idea up :)

--
cody

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

[ozbear]

On Mon, 29 Dec 2003 01:04:09 +0100, "codymanix"
<do*********************@gmx.de> wrote:

> Under normal circumstances there would be no problem as the compiler can
> determine the exact type of the expression from the context.

Yes, but you still seem to have missed the point that it's a
fundamental change in the language philosophy when the type of the
expression requires context. The current language philosophy makes the
language easier to understand, IMO.

It was just an idea. Maybe in the future somebody will pick this idea up :)

<snip>

That will be highly unlikely because the idea is stupid.

Oz

[codymanix]

> >> > Under normal circumstances there would be no problem as the compiler
can

> determine the exact type of the expression from the context.

Yes, but you still seem to have missed the point that it's a
fundamental change in the language philosophy when the type of the
expression requires context. The current language philosophy makes the
language easier to understand, IMO.

It was just an idea. Maybe in the future somebody will pick this idea up :)

<snip>

That will be highly unlikely because the idea is stupid.

There was a lot of people saying some things were stupid, and at a later
time it was recognized that this ideas were not so stupid at all.
For example the developers of java found when they designed the language
that enums were stupid at all. now they recognized this mistake and are
trying to integrate them in the new java versions.

--
cody

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

[Daniel O'Connell]

"codymanix" <do*********************@gmx.de> wrote in message
news:OR**************@TK2MSFTNGP12.phx.gbl...

> > Under normal circumstances there would be no problem as the compiler

can

> > determine the exact type of the expression from the context.
>
> Yes, but you still seem to have missed the point that it's a
> fundamental change in the language philosophy when the type of the
> expression requires context. The current language philosophy makes

the> language easier to understand, IMO.
It was just an idea. Maybe in the future somebody will pick this idea

up :)
<snip>

That will be highly unlikely because the idea is stupid.

There was a lot of people saying some things were stupid, and at a later
time it was recognized that this ideas were not so stupid at all.
For example the developers of java found when they designed the language
that enums were stupid at all. now they recognized this mistake and are
trying to integrate them in the new java versions.

Stupid isn't the issue here, IMHO. I'll accept that its a decent shortcut,
it is simply something I think of as an abberation. Perhaps at some point
someone will feel it needs to be added, there are already features slated
for C# 2.0 that I feel shouldn't be there, but that is irrelevent.
I don't feel the feature is stupid, I just feel its a feature that shouldn't
be in the language, a feature that would be damaging and against the
language philosophy. Part of the reason .NET is designed the way it has been
is the simple understanding that no one language can ever be perfect. Every
one will have problems, every one will have nice features and every one will
be missing a feature that you enjoy immensely in another language. A
language that takes EVERY good idea from EVERY language will likely end up
far more complicated than anything in existance. Some level of filter has to
exist, some level where the feature must be before its of value. This is a
feature I don't think merits inclusion, a feature that doesn't make it up to
that level. It adds complexity for virtually no benifit while intellisense
will allow the vast majority of people to use a very similar feature without
*any* complication to the language. Most features should exist as libraries,
IDE's, and pre-parsers, not as additions to the language. You could use a
pre-parser here, granted, if MS would provide a C# parser library as well as
a capable compile time API, it would be easier to do. One would hope MSBuild
allows a way to run tools across files as they are compiled, etc. I'd
actually rather the compiler team spent its time writing that kind of parser
library than adding features like this.
--
cody

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