协变对象初始值设定项?
假设我有一个类,它的属性是字典
new MyClass()
{
Table = { {"test",true},{"test",false} }
}
但是,在初始值设定项之外我无法执行此操作:
this.Table = { {"test",true},{"test",false} };
为什么初始化器是一种特殊情况?我大胆猜测它与 LINQ 要求、协方差或其他什么有关,但感觉有点不一致,不能在任何地方使用这种初始化程序......
say that I have an class that has a property that is a dictionary<string,bool>, using a object initializer I can use this syntax (which I think looks pretty clean):
new MyClass()
{
Table = { {"test",true},{"test",false} }
}
however, outside of the initializer I can't do this:
this.Table = { {"test",true},{"test",false} };
Why are initializers a special case? I'd hazard a guess that it has something to do with LINQ requirements, covariance or whatnot but it feels a little incongruent not being able to use that kind of initializer everywhere...
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
这个问题有点令人困惑,因为这个问题与 LINQ 无关,与泛型方差无关,并且具有集合初始值设定项以及对象初始值设定项。真正的问题是,据我所知,“为什么在对象创建表达式之外使用集合初始值设定项是不合法的?”
这里的相关设计原则是,一般来说,我们想要操作创建并初始化对象以在其中某处包含“new”一词,作为向读者发出的信号,表明此处正在创建对象。 (是的,C# 中这条规则有一些例外。作为对读者的练习,看看您是否能说出所有这些例外。)按照
您的方式做事会使推理代码变得更加困难。快点,这是做什么的?
第二行是否将 40、50、60 添加到现有列表中?还是用新列表替换旧列表?那里没有“new”,那么读者是否期望创建一个新对象?
当你说
这不会创建一个新列表时;它将 40, 50, 60 添加到构造函数分配的现有列表中。因此,您提出的语法对于是否创建新列表而言是不明确且令人困惑的。
提议的功能既令人困惑又不必要,因此不太可能很快实现。
The question is somewhat confusing, as the question has nothing to do with LINQ, nothing to do with generic variance, and features a collection initializer, as well as an object initializer. The real question is, as far as I can tell "why is it not legal to use a collection initializer outside of an object creation expression?"
The relevant design principle here is that in general, we want operations that create and initialize objects to have the word "new" in them somewhere as a signal to the reader that there is an object creation happening here. (Yes, there are a few exceptions to this rule in C#. As an exercise to the reader, see if you can name them all.)
Doing things your way makes it harder to reason about the code. Quick, what does this do?
Does the second line append 40, 50, 60 to the existing list? Or does it replace the old list with a new one? There's no "new" in there, so does the reader have an expectation that a new object has been created?
When you say
that doesn't create a new list; it appends 40, 50, 60 to an existing list allocated by the constructor. Your proposed syntax is therefore ambiguous and confusing as to whether a new list is created or not.
The proposed feature is both confusing and unnecessary, so it's unlikely to be implemented any time soon.
这个限制比 LINQ 更古老。即使回到 C 语言中,您也可以编写
,但不能使用此语法为数组赋值。
我对 C# 中这背后的原因的猜测是,通常不应该对两个不同的对象使用相同的引用。如果您需要将一个新集合分配给现有引用,很可能您没有很好地设计代码,您可以在定义时初始化该集合,或者使用两个单独的引用而不是一个。
This limitation is far older than LINQ. Even back in C you could write
but you could not use this syntax to assign values to the array.
My guess about the reason behind this in C# is that usually you shouldn't use the same reference for two different objects. If you need to assign a new collection to an existing reference, most probably you didn't design your code very well, and you can either initialize the collection at definition, or use two separate references instead of one.
考虑到您的语法在运行时抛出
NullReferenceException
- 您确定可以使用它吗?编译为以下内容(通过反射器):
如您所见,
Table
未初始化,因此在运行时产生NullReferenceException
。如果您在
Test
的构造函数中创建字典,则类初始值设定项会生成一系列Add
语句,这是初始值设定项中的语法糖(对于IEnumerable
代码>s)。由于我们无法看到或想象的不可预见的副作用,这可能没有在正常代码中引入。埃里克·利珀特也许能够提供帮助,因为他可能对手头的事情有更多的见解。
Considering your syntax throws a
NullReferenceException
at runtime - are you sure you can use it?This compiles to the following (via reflector):
As you can see,
Table
isn't initialized, thus producing aNullReferenceException
at runtime.If you create the Dictionary in the ctor of
Test
, the class initializer produces a cascade ofAdd
statements, which is syntactic sugar in the initializer (forIEnumerable
s).This probably wasn't introduced for normal code due to unforseen side effects we can't see or imagine. Eric Lippert might be able to help out as he probably has more insight on the matter at hand.