Automatic Properties In C# 3

One of the neat things in the next C# is that finally the language supports automatically generated properties. Basically the compiler will create code for you that implements the plumbing of the getters and the setters, which is generally VERY BORING to type.

In short, you can do this in a class:

 

   1: public string Name { get; set; }

Instead of this:

   1: private string m_Name;
   2: public string Name{
   3:     get{
   4:         return m_Name;
   5:     }
   6:     set{
   7:         m_Name = value;
   8:     }
   9: }

Personally I think this is

  1. Brilliant
  2. About damn time!

However this would be an even more intuitive

   1: public property string Name;

 

Or something like this:

   1: [Property]
   2: public string Name;
   3: [property]
   4: public string Age;

 

I know what you want to ask — properties are generally public so isn’t the public in the field definition redundant? Not necessarily. You might for some reason want a property that is private so it’s best to leave the access at the field definition.

That’ my two cents … Thoughts?

kick it on DotNetKicks.com

Share and Enjoy:These icons link to social bookmarking sites where readers can share and discover new web pages.
  • blogmarks
  • co.mments
  • del.icio.us
  • digg
  • Fark
  • feedmelinks
  • Furl
  • LinkaGoGo
  • Ma.gnolia
  • NewsVine
  • Reddit
  • TailRank
  • YahooMyWeb
 

9 responses


  1. “properties are generally public so isn’t the public in the field definition redundant?”

    You could also want to mark a property “internal”. Maybe the default access will be public for properties?


  2. Isn’t this already provided by the IDE in VS2005? You can type Prop string foo and it will generate the Property for you…it’s a code snippet (I think that’s the term)


  3. The problem with your suggestions is, that they leave no (easy) way to say that you only want a “get” _or_ “set” property, and not both at the same time.


  4. @Scott - true, true. But it would ease things if the attribute piggybacked on the field specification

    @Kurt - Yes, but that’s just a clever refactoring. Remember that not everyone uses Visual Studio to write c#! What about those using Delphi, or notepad for that matter? Having it in the language itself, rather than the IDE is a win win situation

    @Fiegling - You have yet to say truer words! I was thinking about that too. And there are ways around that. We could have additional modifiers for the property like so:

    ///This one is read only
    [Property(Read)]
    public string Name

    ///This one is write only, if that makes any sense!
    [Property(Write)]
    public string Age

    ///This one is readwrite
    [Property(ReadWrite)]
    public string DateOfBirth

    In fact on that note, a more keyboard friendly approach is that if you don’t specify read or write, the compiler should assume read/write


  5. I like the “public string Name { get; set; }” syntax better than attributes. Attributes are generally on another line, so you don’t save as much space. The automatic properties syntax is more distinctive to my eyes, especially in cases where I already plan to use an attribute, such as DataContracts.

    My two cents,
    ~ Grahame


  6. It is a bit odd that the automatic properties (so far) generate an essentially inaccessible private field. I was hoping that it would just be a shortcut for the property and field declaration (e.g. Age would generate ‘int m_Age;’ or something), but instead it generates an otherwise inaccessible ‘k__AutomaticallyGeneratedPropertyField0′. This also means that both a getter and a setter are required, since there is otherwise no way to set the value.

    So if you have properties that are just used in classes that are passed around that contain configuration or other “just data” uses, then it’s a fine syntax, but…

    I’d love it if they could provide a slight variation on the theme to allow an actual declared variable and thus allow get-only or set-only, e.g.

    public int Age(int m_Age) { get; set; }
    or
    public int Age(m_Age) { get; set; }
    or
    public int Age { int m_Age; get; set; }

    I’d take the attributes, too, though I understand the one-line appeal.

    – Ritchie


  7. I’m not convinced that the time this will save (not having to type out a full property definition) is worth the design kludge of having a class depend on public properties for access to its own private members..!


  8. I think that this is useful only for the stupid standard C# serialization, which can serialize only properties and no attributes. If I have a read/write member I see no reason to make it a property. I prefer to write:
    class Person
    {
    public string Name;
    }
    which can be changed ususally without breaking any code to
    class Person
    {
    private string name;
    public string Name
    {
    get { return name; }
    set { name = value; }
    }
    }


  9. I was wrong:
    1. I wrote attributes instead of fields.
    2. Serialization works with fileds, but just with the public ones, databinding does not work with them ( http://blogs.msdn.com/abhinaba/archive/2005/09/22/472706.aspx ).

One trackback

Leave a Reply