c# Language request for properties - by George Tsiokos

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 373554 Comments
Status Closed Workarounds
Type Suggestion Repros 2
Opened 10/7/2008 11:09:32 AM
Access Restriction Public


Auto-Implemented properties are great, until you need to implement custom get or set logic. I love the ability to make the field an implementation detail, until you need to implement the property. What if you could continue to hide the field, like this:

public string FirstName {
  get {
    // do more stuff, like lazy init the field
    if (field == null)
      field = "Unknown";
    return field;
  set {
    field = value;

A new keyword, field, references the compiler generated property’s backing field. Also, for readonly fields:

public readonly string Id {
  get {
    return field;
  set { // private is implied
    // do more stuff, like don’t accept null
    if (value == null)
      value = string.Empty;
    field = value;

Where the property would need to be set in the constructor (like read-only fields) as the backing field would be marked read-only. For simplicity, the implementation would use simple property syntax while the compiled output would involve a read-only field, a truly read-only property and a constructor that executes the property’s set body via a static method call each time the field is set in the constructor.
Sign in to post a comment.
Posted by wekempf on 1/26/2009 at 1:28 PM
I blogged about this early on (http://wekempf.spaces.live.com/blog/cns!D18C3EC06EA971CF!234.entry?ccr=4111#comment). I'd prefer some syntactical way to access the backing field from anywhere, and personally think @MyProp or $MyProp or something similar would be ideal. The purpose here would be to save typing AND make the code more readable (as the blog post points out, saving typing is minor, as a code snippet is likely to save you more than auto-props, in many scenarios), and more importantly, provide a mechanism for specifying only what you need to. Following TDD, I might start with:

public int MyProp { get; set; }

Then I add a test that says this should raise a PropertyChanged event. With todays syntax, I have to recode ALL of this. Other's have suggested a refactoring in the IDE to change it to a full property, which isn't bad from a typing perspective, but still complicates the readability of the code. Instead, with my suggestion I only have to refactor the code a little.

public int MyProp
set { @MyProp = value; OnPropertyChange("MyProp"); }

Is this minor syntactic sugar? You bet! But then, so were auto-props. If you buy into them being useful, I think it's an easy transition into seeing the value of being able to easily evolve the implementation and to access the backing field from anywhere.
Posted by George Tsiokos on 10/14/2008 at 3:58 PM
It's not difficult to write the field declaration - I just want to continue to encapsulate it. For example, a class with public FirstName and (private firstName or _firstName) could be accessed via the property or the field throughout the class. If this is a large class, modified by multiple developers over a period of time, this can be a problem. Some could choose the property, while other could choose the field. The introduction of the field keyword allows the encapsulation of the field (in a single class) and forces all developers to use the property in all cases. This could reduce the number of potential bugs as this is the most common use for a property (a property that encapsulated a single field).

The readonly property syntax allows the developer to continue the separation of concerns - even though it can only by set via the constructor. The code *makes sense* there.

Complicated read-only field init code used by multiple constructor overloads has to be implemented by static method for code reuse. Why not create a read-only property that simplifies this scenario?

Thanks for your consideration,

George Tsiokos
Posted by Microsoft on 10/14/2008 at 3:31 PM
Thank you for your proposal.

There are many ways you can imagine expanding the reach of auto-props. This particular one is one that I'm not so hot on because it doesn't really save you much over writing the full implementation - how bad is it to write a simple field declaration.

For the readonly property you propose, it is actually a little worse because you have to define a private setter you wouldn't otherwise have needed.

I do see a slight encapsulation benefit (the field is not accessible outside of the property) but I don't think it justifies the extra syntax.

Thanks again,

Mads Torgersen, C# Language PM