C# Needs a Property keyword like MC++ has now

I've said this before, even directly to Anders, and I'll say it again: C# needs a simpler way to declare properties. Don't believe me Check out this video of a John Lam talk about the future of programming languages that espouses dynamic programming langauges like Ruby:

http://www.ftponline.com/channels/net/reports/vsliveto/2006/multimedia/lam.aspx

About 1/5 of the way into the presentation he gives this example of a piece of code everybody has to write and should be sick of doing by now:

private string _data;

public string Data {
get { return _data; }
set { _data = value; }
}

He's right. There isn't a good reason to have to write this code over and over again just to buy yourself future flexibility. I suspect that the vast majority of property declarations are essentially void of additional logic and are done as properties instead of fields for this very reason. Come'on, you should only have to do this in C#:

public property string Data;

To get a basic property implemented. And then the compiler generates the backing field and the accessor methods for you. Now you might think that seems odd in C# but it isn't. Why Because C# already does this for events. How many event add/remove methods do you write Probably not many because this little declaration:

public event EventHandler Click;

Causes the compiler to create the backing delegate as well as the add/remove methods.

Now this probably doesn't seem like a big deal but it is this sort of "productivity" hit that going to result in dynamic languages taking a big bite out of C#. This is especially since this particular addition doesn't have any dynamic typing implications. And before someone mentions that the C# code editor has snippet support for properties - stop - I know that. However believe it or not, I don't always use VS to write C# code.

P.S. Even "complex" MC++ has a simplified "property" syntax!

Answer this question

C# Needs a Property keyword like MC++ has now

bflotim

(1) What, from the viewpoint of calling code, is the semantic difference between the proposed:

public property string Data;

and

public string Data;

(2) What is the semantic difference from the point of view of code within the implementing class

There's no syntactic different between accessing a field and a property in C#, they're both accessing a member of the class, e.g. object.member. Semantically, they're very different. object.property is short-hand for either object.get_property() or object.set_property(). Obviously, from a client applications point of view these are two drastically different things, which cannot simply be interchanged. You would not simply be able to switch from a field to a property and expect a client application to be able to find that member any more.

That's one of the points of being able to easily add a simple property to a class. A simply property makes the class easier to evolve. If that property needs to exand to use lazy-eval, or perform a calculation (as opposed to a "static" value stored in a field) the interface need not change. If you started out with a field you would have to change the field to a property and change the published interface; breaking any client applications.

dpogo
"It gives flexibility of declaring a property as easy as a field but leaving it open to implement the get/set syntax without having to change the published interface."

That's a good synopsis Peter. The major issue I had with COM programming was all the stinkin' boiler plate code you have to write. I hate that. Now if C# somehow had the same defmacro facility that Lisp has then we wouldn't need Microsoft to add syntatic sugar features like this. We could do it ourselves. :-)
Farzad E.
I completely agree with Keith. I have hundreds of get/set methods in my programs. Not only are they very annoying to write, but it is easy to forget one and then your program won't compile ... again. And in VS, regions frequently auto-open, so it's hard to keep them out of sight, too.
TheReverend

I'm agnostic on the matter myself; I think Visual Studio's refactoring features make it easy to wrap a property around a field rendering a property keyword kind of moot. But, I understand the need to make the language as easy to use outside of Visual Studio....

Yes, it's syntactic sugar; but, I doesn't chance the security of the current get/set syntax--so, I don't think it give any false sense of security, it's no more "exposing" a field than the get/set syntax does. It gives flexibility of declaring a property as easy as a field but leaving it open to implement the get/set syntax without having to change the published interface.
dys

It's times like these I'm glad that C# has that code snippets feature. All we need to do now to create a property is:

prop<TAB><TAB>
Ctrl Right
int/string/object/double/Type/whatever
Right
Type in property backer name
Down down
Type in property name
Enter
Geeter
Also I would be curious to see then a declaration of properties with only a get or set accessor or something more complex like this:

private string data;
public string Data
{
get { return this.data; }
internal set { this.data = value; }
}

Would that then be:
public property public get internal set Data;
or how would you image something like that to look like

Or if it is a property with only a get accessor, declared maybe as:
public readonly property Data
would that then implicitly be not readonly from inside the class

What about properties where there is no direct relationship between a private variable and the property
David Xiong
I'm sure there will be folks who don't use the new syntax just like there will be folks who don't use some of the new C# 2.0 or 3.0 features. However the language has to "keep up" or eventually it will be rendered irrelevant. Dynamic languages and dynamic development styles (like Python, Ruby on Rails, REPL, etc) are on the rise and for good reason - they make developers more productive. Admittedly simplified property syntax is minor in this context but then again I think it is also low hanging fruit. C# 3.0 will go a little way towards addressing productivity but interestingly it seems that the additions are coincidental and were put in mainly to support LINQ. BTW, I'm not arguing for a dynamic/loosely typed C#. However there are plenty of ways the compiler/runtime can make us more productive by eliminating "line noise" and boiler plate code (which is what I consider the current degenerate property get/set code to be).
Robert_Frei

I also agree.

Regarding IDE capabilities that make writing properties easier or keep them out of sight - the IDE should never be used as an excuse not to streamline the language experience. The vast majority of properties are mind-numbingly devoid of logic and the 11 lines used to represent them (if using the standard of braces on separate lines) is just clutter.

David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# Converter
Instant VB: C# to VB Converter
Instant C++: C# to C++ and VB to C++ Converter
Instant J#: VB to J# Converter
Clear VB: Cleans up VB code
Clear C#: Cleans up C# code
David Smith from MSU!
I use that delegate syntax quite often for cleanup of dynamically created and bound objects.

I see that the property keyword would simply the syntax in a special scenario, but I do not know if it is worth to break a consistent syntax (as the complete syntax is still required) to support lazy typers. Personally I think the keyword is unnecessary. After looking through some of my classes, I did only find one maybe two properties which just wrap a private variable. Most of the properties I found serve to give direct access to certain deeper structures which should not be fully exposed , e.g.:
public string Namespace
{
get { return this.currentXmlNode.NamespaceUri; }
}

So probably even if this syntax would be provided I would most likely not use it, to keep a consistent style.
oneniner
Of course - it's so you can change the implementation without changing the interface (I knew that really. ;)

So the proposed "property" keyword would be purely a shorthand, nothing else.

I still don't like the idea, although I can see how it may seem attractive. However...

I don't like the idea of making it too easy to expose fields as read/write values. Sure, you can do that right now by making the field public - but everyone KNOWS that's a bad idea. But it's not just a bad idea because you can't later change the implementation. It's also a bad idea because it allows clients to change the object's fields without the object knowing about it. Letting people do that just by saying "property" could lead them into a false sense of security.

In my (humble) opinion, making it too easy will not encourage people to think about what they're doing. If you make them write the get/set functions, you force them to think about it.

But - hey ho - if it went into the language, I wouldn't be hugely bothered.

[EDIT]
Looking on the Net, it appears people have been discussing this feature since 2002. :)
I'll just go with the flow on this one. :)
#LS
You are forgetting that we would want to use the thing within the class. That means that we would be replacing one kind of clutter with another: inconsistent use of capitals. Not only would that cause a lot of typo's in this name, but it would also cause typo's in names where we do also have a property, and those may lead to all kinds of problems that are awfully hard to track down.

Regards,

Guido
reg3x
I really don't buy that as a valid point. We use public methods from within a class all the time - why would it be any harder typing, say "Data" instead of "_data"

Imagine if it were a public method called Data(). Are you really saying you have problems with calling a method called Data() from within your class methods Of course you don't. And it would be no different with having a public field called Data.

The thing is, of course, is that you are not supposed to have public fields. You are supposed to expose them as properties AND VALIDATE THEM IN THE "SET" METHOD.

I really have two questions:

(1) What, from the viewpoint of calling code, is the semantic difference between the proposed:

public property string Data;

and

public string Data;

(2) What is the semantic difference from the point of view of code within the implementing class
Viktorio
There seems little point to this proposed "Property" keyword. The way I look at it is:

(1) If you don't need to do anything other than allow read access to the underlying field, you can simply use the "readonly" keyword (as someone already stated). In the example given, you can already do this in C#:

private string _data;

public string Data {
get { return _data; }
}

can simply be rewritten as:

public readonly string Data;

If you're allowing complete read/write access, then I'd wonder what your code was up to... It's equivalent to doing "public string Data;"...

However it's possible that I'm not understanding the nuances of what the "property" keyword would do. From the point of view of calling code, what would be the semantic differences between:

public property string Data;

and

public string Data;

(2) If you DO need to do anything other than allow simple read access to the field, you couldn't used the proposed "property" keyword anyway.

So, what's the point It would just end up being a synonym for "readonly"...

By the way: Someone mentioned that they wanted to keep the property get/set methods separate. I do that - where appropriate - by putting them into a separate file via the power of partial classes. I always call that file <classname>.Properties.cs, where <classname> is the name of the class. I also edit the CSProj file so that the ".Properties" file appears nested under the primary class name (just like ".resx" files do).

Now THAT is something I wish the IDE would do - allow you to nest partial class files under the parent class from the IDE!
Silvina
The "get only" case is easy using the "readonly" modifier. Set only, different accessibility on get and set and having no backing store ivar are cases where you wouldn't use the simplified syntax. Just like the MC++ property case and the C# event case, you would still be able to create properties like you do today. BTW, did you know you can do this with events

private EventHandler _clickDelegate;

public event EventHandler Click {
add { _clickDelegate += value; };
remove { _clickDelegate -= value; };
}

The property syntax for C# would then be very similar to the C# event syntax. Use it if you want, which you would for a lot of cases of simple properties. Or implement the accessors yourself if you need more flexibility.
C# Needs a Property keyword like MC++ has now

Answer this question