Are there any plans for "extension properties" in a future version of C#?

Question

I've thought of this before and it came to mind again when reading this question.

Are there any plans for "extension properties" in a future version of C#?

It seems to me they might be pretty stright-forward to implement with a little more "compiler magic". For example, using get* and set* prefixes on extension method names would turn that method into an extension property:

    public class Foo
    {
        public string Text { get; set; }
    }
    public static class FooExtensions
    {
     public static string get_Name(this Foo foo)
     {
      return foo.Text;
     }
     public static void set_Name(this Foo foo, string value)
     {
      foo.Text = value; 
     }
    }

Are there any technical restrictions which would prevent this? Would this create too much stuff going on behind the scenes? Not important enough to be worth the effort?

Answer 1

Although I don't think what you're proposing is a good idea, you can get pretty much the same thing with the upcoming dynamic type in C# 4. Part of what is planned is to allow new properties and methods to be added at runtime to existing objects and types. One difference is that you won't have the compile-time checking of an extension property.

Answer 2

The official site for feature requests is http://connect.microsoft.com/VisualStudio.

There has already been a request for extension properties here.

Microsoft's answer on 7/29/2008 included the following:

Extension properties are a common request, and we actually got quite far with a design for the next version of the language, but ultimately had to scrap it because of various difficulties. It is still on our radar.

Answer 3

Generally I think this would encourage poor practice. Properties are supposed to represent some kind of state about the object in question, whereas methods should represent units of work. But many developers tend to put computationally intensive or relatively long-running code in the getters and setters where they would be much more appropriate as methods. Extending an object is not the same as deriving from it. If you need to add properties, from a philosophical perspective you're talking about needing to add stateful information to the object. That should be done by deriving from the class.

Answer 4

I'm not sure how that would work. Extensions have to be static, so the property itself would have to static. The means whatever you use to back these properties would also be static. But expect your planned use for these expects them to be associated with the instances indicated by the this keyword rather than the type itself.

Answer 5

"Extension properties" are available today via inheritance. Adding such a beast would encourage poor oop practices and generaly be more trouble than its worth.

Answer 6

There might be something to be said about that kind of trick.

Just look at Attached properties in WPF. They do give tremendous power for declarative behavior attachment. But I'm not sure what that would look like outside of a declarative context...