Here’s a bit of code i just got through debugging…

public Point Point { get; private set; }

public void Offset(Point origin)
{
  Point.Offset(-origin.X, -origin.Y);
}

Can you tell what’s wrong here? Let’s just say that the Offset won’t take.

structs are value types, which means anytime you pass one around you get a new copy. So far so good. And that means when you expose a struct value via a property, the accessing party always is looking at a copy. Again, fine, after all when you do a set you change the stored value and if you need to manipulate it, you just manipulate the actual struct.

Enter Automatic properties and you might forget about this last detail and not realize that you never get access to the underlying value, even from within the class. I.e. when I call Point.Offset, i’m calling it on the copy that was passed to me and the resulting value is immediately thrown away. So i just went back to using the property to facade a private Point, which i can now manipulate inside of Offset. Duh.

Just a quick thought on on Automatic properties in C# 3.0 (.NET 3.5, Orcas, whathaveyou). I, like most .NET developers, have spent too much time writing

private string foo;

public string Foo
{
 get { return foo; }
 set { foo = value; }
}

This can now be replaced with

public string Foo { get; set; }

Now that’s nice and all, but for the most part it doesn’t seem like a big step up from just making your field public. Now, you do get the benefit of being able to use this property in places where reflection is used for exposing properties, i.e. in most data-binding scenarios, which don’t accept public fields. And it let’s you implement interfaces, since they also can’t define public fields. But that’s a lot more useful, at least to me is replacing

private string foo;

public string Foo { get { return foo; } }

with

public string Foo { get; private set; }

Now you can create those read-only properties with very simple, clean syntax. That’ll clean up a lot of code for me.

But finally we still have the scenario where properties have side-effects, like calling the event trigger for INotifyPropertyChanged. This cannot be expressed with automatic properties and we’re back to defining a separate private field. What I would love to see is some syntactic sugar along the lines of

public string Foo
 : private _foo
{
 get;
 set
 {
   string previous = _foo;
   _foo = value;
   if(previous != _foo)
   {
     OnPropertyChanged("Foo");
   }
 }
}

I know this doesn’t buy that much in syntax terseness (the get is shorter and you don’t have to define the type of _foo), but it means that the private storage used by the property is part of the property definition, which makes the definition that much more easy to read, imho. That, or allow pre and post conditions for set in Automatic Properties, although the syntax i can think of for that doesn’t seem cleaner than the above.