Automatic Properties

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.

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?

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.

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 :)

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.

@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.

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...

Also not to forget data binding. Databinding will only work with Properties and not with fields

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; }
}