枚举问题 [英] enum question

问题描述

为什么我总是要在enum

成员面前写下枚举类型的名称？


为什么不简单地写红色代替红色？编译器总是知道

哪种类型是预期的，因此不会发生冲突，编译器可以只需查看预期类型的​​枚举成员。


不是更简单，更简单吗？我认为这不是技术上的理由

冗长的语法。

在c ++中，编写类型也不是必需的，为什么它在c＃中？


cody


[免费软件，游戏和幽默]
www.deutronium.de.vu || www.deutronium.tk

解决方案

" codymanix" <做********************* @ gmx.de>在消息中写道

新闻：Oo ************** @ TK2MSFTNGP12.phx.gbl ...

为什么我总是有在
enum成员面前写下枚举类型的名称？

为什么不简单地写Red而不是Color.Red？编译器总是知道
期望哪种类型，所以不会发生冲突，编译器可以简单地查找期望类型的枚举成员。

不是那样的更简单，更简单？我认为这不是技术原因。冗长的语法。
在c ++中，编写类型也不是必需的，为什么它在c＃中？

为了简单起见而且标准化。在C＃中没有其他东西可以像这样工作，就像这样，本地人之外的所有东西都使用了一个对象引用（

隐含了这个或一个显式的）。添加非类型的枚举会破坏

模具。它还使得不清楚究竟什么是红色。是。删除当前的

功能最终可能会降低简单性。全局性是坏的，将特定类型的成员推向全球层面的情况更糟。控制类型分辨率的

规则很复杂，根据类型添加隐含的

分辨率肯定不需要。


我保留重申这一点，人们似乎无法得到它。 C＃不是C ++，而且带来C ++中每个功能的
都是个坏主意。这是一个我没有的功能

认为在C ++中特别有吸引力，更不用说C＃了。如果你想使用

语法，MC ++完全对你开放。

cody

[免费软件，游戏和幽默] www.deutronium.de.vu || www.deutronium.tk

我想在帖子中补充一点，这正是Intellisense的用途。
:-)

虽然我必须承认VB的intellisense在这个场景中的响应速度要快一些。

intellisense让你不必输入大量的额外字符，并且

最后，代码更明确。


-Rob Teixeira [MVP]


Daniel O康奈尔" < onyxkirx @ - NOSPAM--comcast.net>在消息中写道

新闻：OF ************* @ TK2MSFTNGP11.phx.gbl ...

" codymanix" <做********************* @ gmx.de>在消息中写道
新闻：Oo ************** @ TK2MSFTNGP12.phx.gbl ...

为什么我总是要写名字在enum

成员面前的枚举类型？

为什么不简单地写Red而不是Color.Red？编译器总是
知道哪个类型是预期的，因此不会发生冲突，编译器
可以简单地查找期望类型的枚举成员。

不会那样更简单，更简单？我认为没有技术原因那个详细的语法。
在c ++中，编写类型也不是必需的，为什么它在c＃中？

为了简单起见而且标准化。在C＃中没有其他东西可以这样工作，本地人之外的所有东西都使用对象引用（
隐式或隐式）。添加非类型的枚举会打破这种模式。它还使得不清楚究竟什么是红色。是。删除当前的功能最终可能会降低简单性。 Globals很糟糕，将特定类型的成员推向全球层面的情况更糟。控制类型分辨率的
规则很复杂，当然不需要添加基于类型的隐式
解决方案。

我一直在重申这一点，人们似乎没有得到它。 C＃不是C ++，

并且引入C ++中的每个功能都是个坏主意。这是一个我不认为在C ++中特别吸引人的功能，更不用说C＃了。如果你想使用那种语法，MC ++对你完全开放。

cody

[免费软件，游戏和幽默] www.deutronium.de.vu || www.deutronium.tk

Daniel O''Connell写道：

" codymanix" <做********************* @ gmx.de>在消息中写道
新闻：Oo ************** @ TK2MSFTNGP12.phx.gbl ...

为什么我总是有在

enum

会员面前写下枚举类型的名称？

为什么不简单写红色而不是Color.Red？编译器总是知道
期望哪种类型，所以不会发生冲突，编译器可以简单地查找期望类型的枚举成员。

不是那样的更简单，更简单？我认为没有技术上的原因。详细的语法。
在c ++中，编写类型也不是必需的，为什么它在c＃中？

简单化和标准化。在C＃中没有其他东西可以这样工作，本地人之外的所有东西都使用对象引用（
隐式或隐式）。添加非类型的枚举会打破这种模式。它还使得不清楚究竟什么是红色。是。删除当前的功能最终可能会降低简单性。 Globals很糟糕，将特定类型的成员推向全球层面的情况更糟。控制类型分辨率的
规则很复杂，当然不需要添加基于类型的隐式
解决方案。

我一直在重申这一点，人们似乎没有得到它。 C＃不是C ++，并且引入C ++中的每个功能都是个坏主意。这是一个我不认为在C ++中特别吸引人的功能，更不用说C＃了。如果你想使用那种语法，MC ++完全对你开放。

是的，我认为人们会得到你所说的。您缺少的是b $ b缺少的是语言设计为*人*使用，他们写了
代码。因此在我看来，编译器团队可能会抛弃一个支持语言可用性的宗教论点。


我很容易发现这是最烦人的语言的特点。


并不仅仅是C ++让它变得更方便。 VB6也是如此。

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

解决方案

"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

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

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.

这篇关于枚举问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！