Wednesday, November 08, 2006 1:30 AM bart

C# Automatic Properties

EnJust went to the talk of Anders Hejlsberg on C# 3.0 titled "C# 3.0: Future Directions in Language Innovation from Anders Hejlsberg". I've been playing around with C# 3.0 for a pretty long time now (somewhere shortly before PDC 05). Basically my intention was to see Anders' approach in introducing the various new features in a concise way, which might be usable in personal future presentations on the topic. Hearing the stuff from the inventor himself is always great, so if you have the chance to go Anders' sessions this week on TechEd, you can see a repeat of this session later today at 5 PM in room 125. Also worth to check out will be the session called "Explore C# 3.0 with Anders Hejlsberg" in room 112 at 1:30 PM.

What I wanted to tell you from a technical point of view is a new much requested feature that's added to C# 3.0 but isn't in the technical (LINQ) preview yet, called automatic properties. Basically it allows you to write stuff like this:

 

public string Bar { get; set; }
which will be translated automatically in something like this:

 

private string foo; public string Bar { get { return foo; } set { foo = value; } }
Lots of powerful stuff coming in C# 3.0, check out my previous posts on the topic as well (see C# 3.0 post category). I have some posts on expression trees in the queue that will appear online shortly. The current posts I'm linking to a sort of a preface to the topic from a computer science perspective with a little example called DynCalc. In upcoming posts you'll see the System.Expressions way to do the same, ultimately resulting in a sample to translate an expression tree in a domain-specific querying language.

kick it on DotNetKicks.com

Del.icio.us | Digg It | Technorati | Blinklist | Furl | reddit | DotNetKicks

Filed under: ,

Comments

# re: C# Automatic Properties

Wednesday, November 08, 2006 2:42 AM by Bjørn Reppen

This is plain dumb in my eyes. Why have automatic get/set properties with no code in them? This is equivalent to simply having a public field.

# re: C# Automatic Properties

Wednesday, November 08, 2006 6:13 AM by bart

Hi Björn,

I might have been a little to brief in my post on this feature, but it isn't dumb at all. The point is the C# compiler will automatically create a private variable for the time being. That is, you say you have the intent to create a property (not a public field), with all the advantages of it, but you don't want to do all the plumbing right now. Later on however, you can still change the thing to have a custom getter or setter. It all comes down to convenience. The prop code snippet in VS2005 is a valid alternative, but on another level.

Btw, this feature is *not* equivalent to having a public field, from metadata perspective for example.

If you have further questions, don't hesitate to contact me or leave a comment.

-Bart

# Automatic Properties in C# 3.0 - Or so the rumor says!

TechEd Europe is on now and Anders Hejlsberg's talk shed light on some new features proposed for C#....

# re: C# Automatic Properties

Wednesday, November 08, 2006 10:18 PM by Keith Hill

It is *far* from dumb. Some of the biggest complaints about languages like C# and Java versus Ruby/Python is what some have dubbed "line noise". That is, a bunch of extra tokens that aren't always really necessary. A good example of this is the "var" keyword in C# 3.0 that is used for type inference. Frankly I would like to be able to type less but still get compile-time type safety. BTW Bart is absolutely write this is far different from just having a public field. It gives you the ability to implement a more complicated property getter/setter in the future without breaking clients. How would you make a public field thread-safe at some point in the future? You can't. With a property, you could do that without breaking the client. This is also very consistent with the way the event keyword works. It generates a private field delegate and Add/Remove methods that you don't see unless you look at the type in Reflector or ILDASM. My only beef is with the syntax. I was hoping for syntax similar to the event syntax e.g.: class Foo { public property string Name; public readonly property int Id; ... } This would get me a future-proofed properties without having to type a lot of boring boiler plate code. And for those who say, well just just the "prop" template in VS 2005 - uh, I don't always write code in VS 2005. I have been known to write simple programs in notepad. :-)

# re: C# Automatic Properties

Wednesday, November 08, 2006 11:37 PM by Michal Talaga

Certainly this is a great feature, especially because mostly my properties are just plain get and set without logic. One problem is that now you cannot access the private field but then, why would you want to? Strange that I haven't heard about it before though.

# Syntax Consistency among Class Members (Events, Properties, and Methods) « Joshua Mouch

# C# 3.0 Automatic Properties explained

Saturday, March 03, 2007 2:34 PM by B# .NET Blog

A few months ago in the TechEd: Developers Europe timeframe I blogged about the Automatic Property feature

# Customizing Visual Studio 2008 and other IDEs (Colors, Fonts, Snippets, and more) | Of Mice and Math.Min()

Pingback from  Customizing Visual Studio 2008 and other IDEs (Colors, Fonts, Snippets, and more) | Of Mice and Math.Min()