5

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?

Community
  • 1
  • 1
Ðаn
  • 10,934
  • 11
  • 59
  • 95

6 Answers6

7

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.

Jason Kresowaty
  • 16,105
  • 9
  • 57
  • 84
7

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.

Ðаn
  • 10,934
  • 11
  • 59
  • 95
Rex M
  • 142,167
  • 33
  • 283
  • 313
  • @J Daniel Smith while it might seem convenient to make that a property, it should be GetFullName() because it does something functional. There is a formal distinction reserved for a reason - it removes any need to spend time debating whether "some work" is "too much" for a property. – Rex M Mar 17 '09 at 02:15
  • 1
    Let's say I have an existing sealed class that exposes it's state as methods (because the original programmers came from java. sigh), and I'd like to use extension properties to clean it up... What's wrong with that? – Orion Edwards Mar 17 '09 at 03:50
  • At any rate, any arguments that hinge on "we can't implement it because people might do something bad with it" are a lame cop-out IMHO. We are professional adults here, not children that you need to take sharp tools away from! – Orion Edwards Mar 17 '09 at 03:51
  • @Orion if you want unlimited access to a sealed class, why don't we just modify the language to ignore the sealed keyword? Extensions and derivations solve two different problems. We shouldn't avoid it because people might abuse it, we should avoid it because it's a bad idea. – Rex M Mar 17 '09 at 04:12
  • 1
    I don't want unlimited access to a sealed class. Extension methods/properties/etc wouldn't give me that anyway. What I actually want is the ability to write more readable code in a clearer way, which extension props would give me – Orion Edwards Mar 17 '09 at 21:37
3

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.

John Feminella
  • 303,634
  • 46
  • 339
  • 357
  • It's the same thing in exactly the same sense that `dynamic` and regular types are the same. Russians have a good obscene joke about that. – Anton Tykhyy Mar 19 '09 at 09:45
2

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...

Denis Troller
  • 7,411
  • 1
  • 23
  • 36
0

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.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
  • Why was this downvoted? You raise a very good question about the static state of extension methods/properties (hence +1). Of course, what people mean is that they want to achieve the same behavior as inheritance provides **but without** actually inheriting. I.e. keep the name of the class and simply keep a helpy-helpy file in a util lib that adds some useful methods and/or properties. Wound be a nice to have... – Konrad Viltersten Jul 14 '15 at 21:44
0

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

Sam Axe
  • 33,313
  • 9
  • 55
  • 89
  • The problem with this is that it is an abuse of inheritance, and it only works if I have total control over the creation of the objects. You can't for example inherit from system.string. – Orion Edwards Mar 17 '09 at 03:53
  • It's not available, C# doesn't support multiple inheritance so it's actually quite easy to bump into situations where it's simply not possible to have a clean design due to this limitation, if fact, I have run in real life into the exact example "uncle bob" mentions on his blog http://blog.cleancoder.com/uncle-bob/2015/01/08/InterfaceConsideredHarmful.html and extension properties would be a viable solution to the proposed problem – Eduardo Wada Jun 18 '15 at 13:57