Search

Add initialization to automatic properties in C# by Laughing John

Closed
as Won't Fix Help for as Won't Fix

37
Sign in to vote
0
Sign in to vote
Sign in
to vote
Type: Suggestion
ID: 361647
Opened: 8/13/2008 8:19:54 AM
Access Restriction: Public
0
Workaround(s)
Automatic properties should be a useful shortcut on the many times you need standard property handling with a private backing variable.

However, automatic properties as they are implemented now are next to useless. This is because with reference types you nearly always want to create a new object rather than just leave the reference null. This is particularly noticeable with strings.

Also there is no quick way to refactor an automatic property into a standard property.

I've lost count of the number of times I've used an automatic property then had to convert it to 'standard' property syntax just so I can initialize the private variable.

This is made worse because the "prop" snippet now generates an automatic property and there is no easy way to refactor an automatic property to a standard one. (note: you can add the old snippet back in).

This means that this time saving feature actually introduces more typing.
Details (expand)
Product Language
English

Version

Visual Studio 2008 Service Pack 1
Operating System
Windows XP Professional
Operating System Language
English (UK)
Problem Statement
Declaring the following automatic property

public string MyString { get; set; }

When you try to reference the MyString property it is null and on many occasions this is not what you want. This is also true of custom classes:

public MyClass MyObject { get; set; }
Proposed Solution
1) Allow initialization on an automatic property. Something like this:

public string MyString { get; set; } = String.Empty;
public MyClass MyObject { get; set; } = new MyClass();

2) Add an option from the right-click "Refactor menu" in Visual Studio to refactor an automatic property into a fully blown one.

public string MyString { get; set; } = String.Empty;

Becomes:


public string MyString
{
get { return _myString; }
set { _myString = value; }
}

This second part is particularly important if we can't initialize automatic properties as it would allow us to easily convert them to full blown ones.

3) Add the old property style snippet back in - or give a choice of automatic v.s. standard when using the the 'prop' snippet.
TAP Code (if applicable)
 
      You can indicate your satisfaction with how Microsoft handled this issue by completing this quick 3 question survey. [Details]

 

File Attachments
0 attachments
Sign in to post a comment.
Posted by Grant Trimble on 8/22/2008 at 5:00 AM
Good comment. Sounds a bit like the initializers for generic lists which where missing in C# 2.0 but was added in 3. Please add for 3.2 or 4, if possible
Posted by Mick Lang on 8/24/2008 at 11:31 PM
I agree. Automated properties are a bit of a trap, if you wish to add an intializer, there's no refactoring tool to convert it to a standard property, in this case you do end up typing twice as much as you would have if you had implemented an ordinary property to begin with. The other trap for automated properties is the inability to set a break point on an automated property's get or set accessor in Visual Studio.
Posted by int19h on 8/29/2008 at 2:51 AM
In fact, breakpoints on automatic properties could use a separate ticket.
Posted by Microsoft on 9/15/2008 at 2:22 PM
Thank you for your suggestion!

I'll reply to the language suggestion, and then pass this issue on to the IDE team to comment on the VS suggestions.

Automatically implemented properties are limited in several ways. We were very cautious when we introduced them to not make this an overblown feature. Some may claim that the feature is now "underblown".

One of the features we should consider is initialization like you propose. It is not as easy as it sounds though: the next thing you want is for the constructor to initialize the backing field, but it can only do that through the setter, which might not be what you want.

All that said, we could come up with something. We haven't for the upcoming version of C# and it is unlikely that we will be able to add this feature, as we have a very full plate of features already. However we will track this for discussion in the next release after that.

Thanks again,

Mads Torgersen, C# Language PM
Posted by Laughing John on 9/15/2008 at 5:24 PM
Thanks for looking at this Mads.

I think it's fine if the C# team do not wish to do anything about this as I can continue to use the full property syntax.

My issue is the way that automatic properties have been 'sold' to us by the replacement of the prop snippet (and the marketing). I know we can add it back in but for me it's the snippet I used most often and given the short-comings of automatic properties it seems daft to push us in that direction and effectively slow us down.

Thanks again,
LJ
Posted by Microsoft on 9/18/2008 at 3:20 PM
Hi LJ,

Thanks again for the suggestion. Regarding your suggestions for the IDE, I'm happy to say that due to the customer feedback we've received, we've added the original prop snippet back in for our next release as "propfull". Additionally, we have heard the suggestion for refactoring auto properties to "normal" properties before and its on our list of features to consider before each release. If you have any further questions/comments about the IDE interaction with auto properties, feel free to shoot me an email directly at djpark@microsoft.com.

Thanks!
DJ park
C# IDE PM
Posted by Laughing John on 9/19/2008 at 3:50 AM
Excellent news! Thanks for your time.
Posted by W.R. Isaacs on 9/23/2008 at 9:11 AM
Lack of initialization or constructor control makes the feature practically worthless for properties returning a reference type.
Posted by George Tsiokos on 10/7/2008 at 11:07 AM
Another request for properties in c#
http://george.tsiokos.com/posts/2008/10/07/c-sharp-language-request-for-properties/
Posted by Kyrenia1 on 2/12/2009 at 2:34 PM
This would also provide a way to avoid the mistake of initializing anything in the Setter, when obviously the Getter could be called first.
Posted by Daniel Smith on 8/20/2009 at 8:03 AM
It's incredibly disappointing that VB.NET 4.0 is getting this exact feature, despite no requests on Connect, yet the large number of people who have requested this for C# are completely ignored :-(