C＃需要什么 [英] What C# Needs

问题描述

自1992年开始使用VB开发以来，我现在非常感兴趣的是对B＃感兴趣的
。我已经用

C＃编写了几个应用程序，我确实喜欢这种语言。


C＃需要什么：


有些事情我确实相信MSFT应该做什么来提高C＃，但是。


我知道在Whidbey中VS.NET的发布目前正在开发中，VB.NET将获得好的编辑 - 并且 -

继续背部。欢呼！什么是不幸的（如果我错了的话，还是正确的话），C＃开发人员不会喜欢这个

功能。这是非常不幸的，因为这个功能

应该存在于所有编程语言中。


C＃需要的另一件事是更好的智能感知（

好像vb.net）。我找到了一些实例，我点击了

ctrl +空格键，C＃中没有任何反应。我在VB.NET中编写了相同的代码，然后点击了ctrl + spacebar和

intellisense弹出就好了。


它不像C＃开发人员不想拥有VBers所享有的这些不错的视觉和功能特性

如果他们选择"使用它们。请记住

字词选择。不要强迫开发人员使用

这些功能。允许他们禁用或启用它们，因为需要
。这是一个开发环境的人，为什么不能使用这个dev env好处的所有.NET语言？

Having developed with VB since 1992, I am now VERY
interested in C#. I''ve written several applications with
C# and I do enjoy the language.

What C# Needs:

There are a few things that I do believe MSFT should do to
improve C#, however.

I know that in the "Whidbey" release of VS.NET currently
under development, VB.NET will get good ole "edit-and-
continue" back. Hurray! What''s unfortunate (and correct
me if I''m wrong) is that C# developers won''t enjoy this
feature. This is very unfortunate because THAT feature
should exist in ALL programming languages.

Another thing that C# needs is better intellisense (as
good as vb.net). I''ve found a few instances where I hit
ctrl+spacebar and nothing happens in C#. I write the SAME
exact piece of code in VB.NET and hit ctrl+spacebar and
the intellisense pops up just fine.

It''s not like C# developers don''t want to have these nice
visual and functional features enjoyed by VBers available
to them if they "choose" to use them. Keep in mind the
word "choose". Don''t FORCE developers to have to use
these features. Allow them to disable or enable them as
needed. It''s ONE development environment folks, why can''t
all .NET languages using that dev env benefit?

推荐答案

Keith K< kp ****** @ linuxmail.org>写道：

Keith K <kp******@linuxmail.org> wrote:

自1992年开始用VB开发以来，我现在对C＃非常感兴趣。我已经用C＃编写了几个应用程序并且我喜欢这种语言。

C＃需要什么：

Having developed with VB since 1992, I am now VERY
interested in C#. I''ve written several applications with
C# and I do enjoy the language.

What C# Needs:

< snip>


这些都不是C＃建议 - 他们是Visual C＃或Visual

Studio .NET建议。最后我听说，E& C并不排除

Whidbey无论如何 - 不确定Intellisense的改进是否是你的b $ b之后。


就个人而言，有些事情我会更喜欢用*语言*（以及C＃编译器应该识别的

属性），例如：


o显式控制beforefieldinit

o具有单独访问/变异保护级别的属性（我相信

我们得到这个）

o在属性中声明的变量，然后通过其他方法无法访问

（除非可能有指定的新属性

，例如AccessPropertyFields，允许更容易的序列化）

o可能是在派生类上指定的属性，

会告诉编译器有效地继承构造函数
来自基类的
（即自动提供存根版本

只调用基本版本）


-

Jon Skeet - < sk *** @ pobox.com>
http://www.pobox.com/~skeet/

如果回复小组，请不要给我发邮件

<snip>

Neither of these are C# suggestions - they''re "Visual C#" or "Visual
Studio .NET" suggestions. Last I heard, E&C wasn''t ruled out for
Whidbey anyway - not sure about the Intellisense improvements you''re
after.

Personally, there are things I''d rather see in the *language* (and
attributes which the C# compiler should recognise) such as:

o Explicit control over beforefieldinit
o Properties with separate access/mutate protection levels (I believe
we''re getting this)
o Variables declared within properties, which then can''t be accessed
by other methods (except possibly where there''s a new attribute
specified, eg AccessPropertyFields, to allow easier serialization)
o Possibly an attribute to be specified on the derived class which
would tell the compiler to effectively "inherit" the constructors
from the base class (ie automatically provide stub versions which
just call the base version)

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

-----原始消息-----
Jon Skeet< sk *** @ pobox.com>写道：

-----Original Message-----
Jon Skeet <sk***@pobox.com> wrote:

就个人而言，有些东西我宁愿在
*语言中看到*（以及C＃编译器应该识别的属性），例如

Personally, there are things I''d rather see in the *language* (and attributes which the C# compiler should recognise) such

as ：
< snip>

哦，还有一些方法可以访问命名的索引器（以及
也可以更好地命名它们的方式）。泛型将使这个
稍微不那么重要，但提供一个价值高达b $ b的高效，类型安全的只读索引器仍然非常容易。

-
Jon Skeet - < sk *** @ pobox.com>
http ：//www.pobox.com/~skeet/
如果回复小组，请不要给我发邮件
。

as:
<snip>

Oh, and also some way of accessing named indexers (and preferrably anicer way of naming them, too). Generics will make this slightly lessimportant, but it''s still not terribly easy to provide an efficient,type safe, read-only indexer.

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

你是对的。有许多改进可以将

添加到该语言中。我的建议是

主要围绕IDE。真的，我只是没有看到

为什么任何IDE，编译器和调试器等增强功能

应该是语言。具体。如果一种语言受益，那么所有语言都应该受益。

You are correct. There are a number of improvements that
could be added to the language. My suggestions were
mainly centered around the IDE. Really, I just don''t see
why any IDE, compiler, and debugger, etc. enhancements
should be "language" specific. If ONE language benefits,
then ALL languages should benefit as well.

" Jon Skeet" < SK *** @ pobox.com>在消息中写道

新闻：MP ************************ @ news.microsoft.com ...

"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@news.microsoft.com ...

Keith K< kp ****** @ linuxmail.org>写道：


<这里的一些信息......>

o明确控制beforefieldinit
o具有单独访问/变异保护级别的属性（我相信
我们得到这个）


根据开发聊天，这是正确的 - 我们得到了这个（关于时间！）

:-)

粉了一个老版本的VB，实际上这是正确的。

我相信你可以在msdn.com或csharp.net上找到成绩单。

o在属性中声明的变量，然后无法通过其他方法访问
（除非可能指定了新的属性
，例如AccessPropertyFields）更容易序列化）


我不确定我是否理解这一点。我的意思是，本地变量不能被其他方法访问，因为它会影响序列化。

这里可能会有一些有趣的东西，所以我'好奇:-)

o可能是在派生类上指定的属性，它将告诉编译器有效地继承来自基类的构造函数（即自动提供只调用基本版本的存根版本）


嗯，这里有很多这个关于其他OOP语言的谈话，以及

所有我能说的是它开始了语言civel大战:-)

有一些合理的理由为什么构造函数不是继承和

可以覆盖（好吧，没有继承意味着没有可以超越的定义我想b / b
）个人，我不介意看构造函数是界面的一部分，

所以你可以做一些事情，比如在他们绝对需要
的时候正确地授权构造函数签名（比如序列化 - ISerializable，作为

例子。


-Rob [MVP]

-
Jon Skeet - < sk *** @ pobox .com>
http://www.pobox.com/~skeet/
如果回复小组，请不要也给我发邮件

Keith K <kp******@linuxmail.org> wrote:
<some snippage here...>
o Explicit control over beforefieldinit
o Properties with separate access/mutate protection levels (I believe
we''re getting this)
According to a dev chat, that is correct - we are getting this (about time!)
:-)
Chalk one up to old VB, which actually did this correctly.
I believe you can find the transcript at either msdn.com or csharp.net.
o Variables declared within properties, which then can''t be accessed
by other methods (except possibly where there''s a new attribute
specified, eg AccessPropertyFields, to allow easier serialization)
I''m not sure I understand this properly. I mean, local variables can''t be
accessed by other methods as it is, and how does this affect serialization.
There might be something interesting here, so i''m curious :-)
o Possibly an attribute to be specified on the derived class which
would tell the compiler to effectively "inherit" the constructors
from the base class (ie automatically provide stub versions which
just call the base version)
Well, there''s been a lot of this kind of talk over other OOP languages, and
all I can say is that it starts language civel wars :-)
There are some legit reasons why constructors aren''t inherited and
overridable (well, no inheritance means no overridable by definition i
suppose).
Personally, I wouldn''t mind seeing constructors being part of the interface,
so you can do things like properly mandate constructor signatures when they
are absolutely required (like for serialization - ISerializable, as an
example).

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

这篇关于C＃需要什么的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！