When I first read about properties in C#, I was a bit excited and a bit confused. I was glad to see so many inventions, including properties,designed to help programmers be more productive. But on the other hand, why do properties require so much typing just to declare a variable? And why does it seem we need to create two variables to do the job of one?
For review, this example shows the minimum syntax to create a property in C#:
/////////////////////////
private int myval;
public int Myval
{
get
{
return myval;
}
set
{
myval = value;
}
}
/////////////////////////
In my opinion, the problem with the above code is that programmers must declare two identifiers, which are confusingly similar: myval and Myval. You have to remember which one of the two you are allowed to use from outside the class. Of course, for a newbie, it's even more confusing because a third identifier, "value", is used without even being declared. Okay, so you quickly learn that "value" is a keyword, not an identifier. But still, it should be easier than this.
Here is a proposed alternative syntax that accomplishes the same thing and is also extensible:
/////////////////////////
public int property Myval
{
get;
set;
}
/////////////////////////
The new "property" keyword declares that Myval is an actual variable definition. As a property, the variable is only accessible through the provided getter/setter, which are automatically generated in this case. By giving us an automatic, albeit simplistic, getter/setter, it's like the compiler is saying: "If you cannot afford a getter or a setter, one will be appointed for you." I recall the C language standards committee came up with that bit of levity when they adopted function prototypes. Well, it's about as humorous as we can expect standards bodies to be.
Getting back to the subject, you can see that the simplified syntax reduces the amount of code required, and the number of confusingly similar identifiers from three to one.
Well, sort of. We can say three to two, at least. The free setter provided by the compiler, ummm, isn't very valuable. In fact, we may as well just declare a regular variable as have a property with a free setter. So it's true that the value keyword is still required to implement a real-world setter, but this new style is safer because the class author may not inadvertently violate the variable range rules by bypassing the setter from within other member functions. In other words, having one identifier instead of two avoids the risk of the class author assigning an inappropriate value directly to myval (not Myval) from other code within the class.
You may say this new syntax seems unusual. Hey man, what do you think everybody says the first time they see a for loop in C/C++/Java/C#? As practical as the for loop is, it also proves the point that the syntax of a language rules! So just as the syntax of an enum is different from that of a struct, the property keyword is similar in that it also establishes special rules for the syntax that follows within the braces.
The automatic (free) getter/setter in the simplified property syntax can be easily extended by replacing either or both with a function, as C# currently requires. But either way, you still have the option to avoid creating an unnecessary identifier for this common programming task. For example:
/////////////////////////
public int property Myval
{
// usually we don't need a special getter, so one will be appointed for us
get;
// if we need a special setter, we do it without an extra variable
set
{
if (value > 10)
throw new Exception();
else
// within the scope of a property, the compiler "knows"
// that assignment is not a recursive call...
Myval = value;
}
}
/////////////////////////
I hope the C# community will speak up about this, and further refine the concept, so Microsoft and ECMA will consider this for future versions of the language.