views:

141

answers:

2
+9  Q: 

Initializer syntax

Hi

I like the C# 3 initializer syntax and use it a lot, but today while looking in Reflector, the following came up:

var binding = new WSHttpBinding
{
  ReaderQuotas = { MaxArrayLength = 100000 },
  MaxReceivedMessageSize = 10485760
};

At first I thought it was a mistake, but it does compile! Guess I am still learning new stuff all the time. :)

From what I can tell, it sets the MaxArrayLength property of the ReaderQuotas property of the WSHttpBinding.

Does this syntax create a new ReaderQuotas object and then set the property, or does it assume the property to be initialized already? Is this the general way one would use to initialize 'child' properties?

I do find the syntax a bit confusing...

+8  A: 

No, that doesn't create new objects unless you use = new SomeType {...}:

var binding = new WSHttpBinding
{
    ReaderQuotas = new XmlDictionaryReaderQuotas { MaxArrayLength = 100000 },
    MaxReceivedMessageSize = 10485760
};

Your example shows the initializer syntax for setting properties of existing sub-objects. There is also a similar syntax for calling "Add" methods on collections.

Your code is broadly comparable to:

var binding = new WSHttpBinding();
binding.ReaderQuotas.MaxArrayLength = 100000;
binding.MaxReceivedMessageSize = 10485760;
Marc Gravell
Looks identical to that, is there more than just a syntactical difference? Looks as though (unless ReaderQuotas is initialized in the contructor of WSHttpBinding) it should throw an exception
James
Thanks, it just took me by surprise :) I assume by 'Add' you mean like a collection initializer?
leppie
@james: I would expect an exception in that case, but not having source code could prove confusing, if you dont know what gets done in the constructor. Some constructor overloads may or may not initialize that property, which will lead to even more confusion.
leppie
Not worth a whole extra answer - but this is discussed in Chapter 8 of C# in Depth. The first edition version of this chapter is available free from http://manning.com/skeet/
Jon Skeet
Thanks Jon :)))))
leppie
James, the difference is subtle. Though the code is semantically equivalent to that, we actually generate "temp = new Binding(); blah blah blah; var binding = temp;" Why? Because *the variable "binding" must not be used inside its own initializer!* That would be rather a chicken-and-egg problem. If we generated the code exactly as Marc suggests then "binding" would be initialized *before the initializer code runs*, and someone could potentially observe "binding" in its partially-initialized state.
Eric Lippert
I might be wrong, but IIRC it also gets slightly different if there are multiple properties in the assignment, since in the initializer syntax the member is only evaluated once - so `..., SomeProp = { Foo = 1, Bar = 2 }` would be `var tmp = obj.SomeProp; tmp.Foo = 1; tmp.Bar = 2;`, and not `obj.SomeProp.Foo = 1; obj.SomeProp.Bar = 2;`.
Marc Gravell
Thanks guys very interesting!
James
+2  A: 

It is a bit confusing, I agree.

You should read section 7.5.10.2 of the specification; it is all explained there. For example:

A member initializer that specifies an object initializer after the equals sign is a nested object initializer, i.e. an initialization of an embedded object. Instead of assigning a new value to the field or property, the assignments in the nested object initializer are treated as assignments to members of the field or property. Nested object initializers cannot be applied to properties with a value type, or to read-only fields with a value type.

A member initializer that specifies a collection initializer after the equals sign is an initialization of an embedded collection. Instead of assigning a new collection to the field or property, the elements given in the initializer are added to the collection referenced by the field or property.

Eric Lippert