enum question

  • Thread starter Thread starter codymanix
  • Start date Start date
codymanix said:
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.
Click to expand...

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)
 
- for instance members in a class I can omit the "this"-keyword since
Agreed but that's because this notation implies you're dealing with an
instance.
Click to expand...

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.
This is bad practice. I had no idea C# would let you do such a thing.
Click to expand...

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.
This is also bad practice as it not self-documenting in the least.
Click to expand...

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!!!
 
Frank Oquendo said:
This is also bad practice as it not self-documenting in the least.
Click to expand...

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.
 
Frank Oquendo said:
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.
Click to expand...

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.
 
object x = Red;
Does that mean Color.Red or SomethingElse.Red?
Click to expand...


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.
 
- you can omit the "private" keyword
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.
Click to expand...

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
Click to expand...

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.
Click to expand...

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.
 
codymanix said:
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.
Click to expand...

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).
 
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.
Click to expand...


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.
 
object x = Red;
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).
Click to expand...


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()
{
}
 
why not simply writing Red instead of Color.Red? The compiler always
knows
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.
Click to expand...


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 said:
bar.Foo(Red); // the compiler knows that Color is desired here and looks up
the member Red in Color.
Click to expand...

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.
Click to expand...

So the expression itself has no type, giving rise to the problem
above...
 
bar.Foo(Red); // the compiler knows that Color is desired here and
looks up
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.


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


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.
 
codymanix said:
Under normal circumstances there would be no problem as the compiler can
determine the exact type of the expression from the context.
Click to expand...

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.
 
Under normal circumstances there would be no problem as the compiler can
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.
Click to expand...


It was just an idea. Maybe in the future somebody will pick this idea up :)
 
Under normal circumstances there would be no problem as the compiler
can
<snip>

That will be highly unlikely because the idea is stupid.
Click to expand...


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.
 
codymanix said:
compiler up


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.
Click to expand...

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
Click to expand...
 
Back
Top