c＃2.x功能请求 [英] c# 2.x feature requests
问题描述
不知道这是否是正确的论坛，但是这里是..
- 属性获取和设置成员的独立访问级别修饰符
例如。 public get，protected set，set提供验证/线程同步
设施
- 默认的类成员访问权限设置为受保护而非私有
- automagic添加/删除事件成员的线程并发管理
例如。自动管理与+ =
和 - =事件超载相关的线程并发问题
...
其他任何人都在评论
- 史蒂夫
Don''t know if this is the correct forum for this, but here goes..
- independent access level modifiers for property get and set members
eg. public get, protected set, set provides validation / thread sync
facilities
- default class member access set to protected rather than private
- automagic thread concurrency managment for the add / remove event members
eg. automagic management of thread concurrency issues associated with +=
and -= event overloads
...
anyone else care to comment
-- Steve
推荐答案
steve< st *** @ discuss .microsoft.com>写道：
steve <st***@discussions.microsoft.com> wrote:
不知道这是否是正确的论坛，但这里是..
- 属性获取和设置成员的独立访问级别修饰符
例如public get，protected set，set提供验证/线程同步
设施
那已经处于测试阶段。
- 默认班级成员访问设置为受保护而非私有
值得庆幸的是，测试版中的*不是*。应该使用受保护的访问权限比私有访问（特别是对于字段）更少使用
。另外，
如果你私有但它实际上应该受到保护，那么你可能会在编译时找到它。反过来说，你会知道
直到某些东西使用了非预期的访问...
- 添加/删除事件成员的自动线程并发管理
例如与+ =
和 - =事件重载相关的线程并发问题的自动化管理
Don''t know if this is the correct forum for this, but here goes..
- independent access level modifiers for property get and set members
eg. public get, protected set, set provides validation / thread sync
facilities
That''s already in the beta.
- default class member access set to protected rather than private
Thankfully that''s *not* in the beta. Protected access should be used
more rarely than private access (particularly for fields). In addition,
if you make something private but it should actually be protected,
you''re likely to find out at compile time. The other way round, you''ll
never know until something uses the unintended access...
- automagic thread concurrency managment for the add / remove event members
eg. automagic management of thread concurrency issues associated with +=
and -= event overloads
你想要它做什么？目前它锁定了这个。并且
我认为至少*允许*锁定私人会员
变量，如果编译器决定。
-
Jon Skeet - < sk *** @ pobox.com>
http://www.pobox.com/~skeet 博客： http://www.msmvps.com/jon.skeet
如果回复小组，请不要给我发邮件
What exactly would you want it to do? Currently it locks on "this" and
I believe it will at least be *allowed* to lock on a private member
variable instead if the compiler decides to.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
感谢您的反馈。
" Jon Skeet [C＃MVP]"写道：
Thanks for the feedback.
"Jon Skeet [C# MVP]" wrote:
steve< st *** @ discuss.microsoft.com>写道：
steve <st***@discussions.microsoft.com> wrote:
不知道这是否是正确的论坛，但这里是..
- 属性获取和设置成员的独立访问级别修饰符
例如public get，protected set，set提供验证/线程同步
设施
已经处于测试阶段。
Don''t know if this is the correct forum for this, but here goes..
- independent access level modifiers for property get and set members
eg. public get, protected set, set provides validation / thread sync
facilities
That''s already in the beta.
good
good
- 默认的类成员访问权限设置为受保护而非私有
- default class member access set to protected rather than private
谢天谢地，''*不是*公测。应该使用受保护的访问，而不是私有访问（特别是对于字段）。另外，如果你把某些东西私有但它实际上应该受到保护，那么你很可能在编译时发现它。反过来，你会知道，直到某些东西使用了非预期的访问......
Thankfully that''s *not* in the beta. Protected access should be used
more rarely than private access (particularly for fields). In addition,
if you make something private but it should actually be protected,
you''re likely to find out at compile time. The other way round, you''ll
never know until something uses the unintended access...
足够公平的字段。但总是我发现我想称之为祖先的方法。是的，我同意最好尽可能地封装
，我想当你匆忙时，它会变得有点困难。 ）
fair enough for fields. But invariably I find that I want to call methods
of ancestors. Yes I agree that it is best to encapsulate as much as
possible, I guess it''s just a bit harder when your in a hurry.. ; )
- 添加/删除事件成员的自动线程并发管理
例如。与+ =
和 - =事件重载相关的线程并发问题的自动化管理
- automagic thread concurrency managment for the add / remove event members
eg. automagic management of thread concurrency issues associated with +=
and -= event overloads
您希望它做什么？目前它锁定了这个。并且
我相信如果编译器决定将至少*允许*锁定私有成员
变量。
What exactly would you want it to do? Currently it locks on "this" and
I believe it will at least be *allowed* to lock on a private member
variable instead if the compiler decides to.
我搜索关于事件竞争条件的评论
http://blogs.msdn.com/csharpfaq/arch.../19/93082.aspx
这就是我一直以来接线/断线时要避免使用probs
代表。评论？
#region SomethingHappenedEvent
object SomethingHappenedEventLock = new object（）;
protected event SomethingHappenedEvent mSomethingHappened;
公共事件SomethingHappenedEvent SomethingHappened
{
add
{
lock（SomethingHappenedEventLock ）
{
if（mSomethingHappened == null）
{
//获取所需的任何共享资源处理活动
}
mSomethingHappened + = value;
}
}
删除
{
lock（SomethingHappenedEventLock）
{
mSomethingHappened - = value;
if（mSomethingHappened == null）
{
//释放处理活动所需的任何共享资源
}
}
}
}
protected virtual void OnSomethingHappened（）
{
lock（SomethingHappenedEventLock）
{
if（mSomethingHappened！= null）
{
mSomethingHappened（this，new SomethingHappenedEventArgs（））;
}
}
}
#endregion
-
Jon Skeet - < sk *** @ pobox.com>
http://www.pobox.com/~skeet 博客： http://www.msmvps.com/jon.skeet
如果回复该组，请不要给我发邮件
I googled up this commentary on event race conditions
http://blogs.msdn.com/csharpfaq/arch.../19/93082.aspx
This is what I have been doing to avoid probs when wiring / unwiring
delegates. comments?
#region SomethingHappenedEvent
object SomethingHappenedEventLock = new object();
protected event SomethingHappenedEvent mSomethingHappened;
public event SomethingHappenedEvent SomethingHappened
{
add
{
lock (SomethingHappenedEventLock)
{
if (mSomethingHappened == null)
{
// Acquire any shared resources required for processing event
}
mSomethingHappened += value;
}
}
remove
{
lock (SomethingHappenedEventLock)
{
mSomethingHappened -= value;
if (mSomethingHappened == null)
{
// Release any shared resources required for processing event
}
}
}
}
protected virtual void OnSomethingHappened()
{
lock (SomethingHappenedEventLock)
{
if (mSomethingHappened != null)
{
mSomethingHappened(this, new SomethingHappenedEventArgs());
}
}
}
#endregion
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
" steve" < ST *** @ discussions.microsoft.com>在消息中写道
新闻：0D ********************************** @ microsof t.com ...
"steve" <st***@discussions.microsoft.com> wrote in message
news:0D**********************************@microsof t.com...
感谢您的反馈。
Jon Skeet [C＃MVP]"写道：
Thanks for the feedback.
"Jon Skeet [C# MVP]" wrote:
steve< st *** @ discuss.microsoft.com>写道：
steve <st***@discussions.microsoft.com> wrote:
>不知道这是否是正确的论坛，但是这里......
>
> - 属性获取和设置成员的独立访问级别修饰符
>例如。 public get，protected set，set提供验证/线程同步
>设施
已经处于测试阶段。
> Don''t know if this is the correct forum for this, but here goes..
>
> - independent access level modifiers for property get and set members
> eg. public get, protected set, set provides validation / thread sync
> facilities
That''s already in the beta.
好
good
是的，它很棒。但是我总是会错过C ++中的朋友修饰符或者用Delphi完成的
。
Yes, it''s great. However I''ll always miss the friend modifier in C++ or as
done in Delphi.
> - 默认的类成员访问权限设置为受保护而非私有
> - default class member access set to protected rather than private
谢天谢地，在测试版中'不是*。应该使用受保护的访问，而不是私有访问（特别是对于字段）。另外，如果你把某些东西私有但它实际上应该受到保护，那么你很可能在编译时发现它。反过来说，直到某些东西使用了非预期的访问权限，你才会知道......
Thankfully that''s *not* in the beta. Protected access should be used
more rarely than private access (particularly for fields). In addition,
if you make something private but it should actually be protected,
you''re likely to find out at compile time. The other way round, you''ll
never know until something uses the unintended access...
对于字段来说是公平的。但总是我发现我想称之为祖先的方法。是的，我同意最好尽可能地封装
，我想当你匆忙时，它会变得有点困难。 ）
fair enough for fields. But invariably I find that I want to call methods
of ancestors. Yes I agree that it is best to encapsulate as much as
possible, I guess it''s just a bit harder when your in a hurry.. ; )
呵呵，我从未如此匆忙。另外，我会避免在恐慌时编写虚拟
类。 =）
快乐编码
- Michael S
Hehe, I''ve never been in such a hurry. Also, I would avoid coding virtual
classes when in panic. =)
Happy Coding
- Michael S
这篇关于c＃2.x功能请求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
