OdeToCode IC Logo

Automatic Properties

Wednesday, July 18, 2007

I wrote my first class with automatic properties in Orcas today...

public class FoodFactMessage
public int ID { get; set; }
public string Name { get; set; }

public int Calories { get; set; }

... then I found myself staring at the screen.

It's an interface!
No,it's a class!
Wait, it is a class!

I'd say the syntax is still growing on me.

I'm sure some people will say – why use properties at all? If you don't need special code in the get and set methods – why not just use a public field?

The quick answer is: reflection. There are many forms of magic that will only occur if you expose state using public properties.

Related Links

Karl Wednesday, July 18, 2007
All of the new small features in C# 3.0 are great, but not necessary. The result is that you end up with code that isn't backwards compatible for no good reason.

I wrote a dll for an Orcas project that, a couple weeks later, I wanted to reuse, but couldn't 'cuz of the few lambdas, default properties and collection initializers.

Overall progress is great, it's just the year or two that we transition that sucks.
Jeroen-bart Engelen Wednesday, July 18, 2007
I always use public fields instead of properties and I've never run into a problem. Could you elaborate on what reflection magics will only occur when using properties?
James Wednesday, July 18, 2007
I'm loving automatic properties for this syntax:

public string Name { get; private set; }

Now I can assign the Name in the constructor, and external code can't mutate it. THAT beats a public field hands down, for just a teensy bit more typing.
Daniel Moth Wednesday, July 18, 2007
Hey Scott... on the automatic properties vs public fields angle...

Note that if you use the latter in a class library and later decide you wanted properties, you'd potentially break existing clients (with automatic properties, you just change it to normal properties and add any implementation you fancy). Also properties work in databinding scenarios that fields don't :)
scott Wednesday, July 18, 2007
Jeroen-bart Engelen:

As Daniel pointed out, there are some scenarios where public properties are a must. If you want to use your class with data binding, or with some of the serializers (XmlSerializer), than they use reflection to find public properties only.
Jeroen-bart Engelen Wednesday, July 18, 2007
@Scott & Daniel:
Could it be that the behaviour changed between .NET 1.1 and .NET 2.0?

I do recall some issues with databinding and the need to create properties, but I'm currently reworking a webservice in .NET 2.0 that was originally written in .NET 1.1 and I'm adding new classes that are being serialized (by hand and by the .NET framework itself for SOAP stuff) without properties but with public fields and I've yet to run into a problem.

I created a very small test app just now. Two classes with a string, an int, a float and a DateTime. One class made the fields public and one used properties. The XML that came out the serializer is identical.
Or is my test too simple?

Just curious.
scott Wednesday, July 18, 2007
Well gosh - it looks like the XmlSerializer DOES serialize public fields. My mistake.

Data binding (at least in ASP.NET) still looks at public properties only...
Vikram Wednesday, July 25, 2007
Also not to forget data binding. Databinding will only work with Properties and not with fields
Thomas Eyde Wednesday, August 1, 2007
I still think they should have found a different syntax. As you say, it's difficult to know what we are looking at. This does not follow the principle of least surprice.

I would still like something like:

public property int Id;
private property int Id;
public readonly property int Id;

And, for regular properties, it would be cool to:

public int Id
int id = 1; // field inside of property block, nice when we lazy load.
get { return id; }
Comments are closed.