Why No Extension Properties?

re: Why No Extension Properties?

George Birbilis — Wed, 16 May 2012 09:54:28 GMT

being able to add more constructors via extension methods would save a lot of time to people trying to create for example compatibility layers for porting WPF code to Silverlight (e.g. at ScaleTransform of Silverlight I'm missing a constructor that takes ScaleX and ScaleY params, forcing one to rewrite their WPF code to not pass such params but do set ScaleX/ScaleY explicitly if they want it portable to SL)

re: Why No Extension Properties?

Pete — Tue, 20 Mar 2012 13:09:37 GMT

> Properties are meant to store some kind of state in relation to the instance of the object it exists on.

If you´re referring to setters. But there are lots of cases where you can use getters that return the result of, say, some calcs on the fly not having to access private fields.

Would have loved to see this feature on C# 5 ... :(

re: Why No Extension Properties?

Michael Perrenoud — Fri, 25 Nov 2011 14:39:10 GMT

To all of those who wonder why extension properties aren't just an extension of extension methods let's examine the purpose of a property first. Properties are meant to store some kind of state in relation to the instance of the object it exists on. Extension methods store no state on the object itself, rather they simply interrogate the object and add some additional functionality. They may in fact set values of properties that already exist in the objects definition, but they aren't storing any new dynamic state.

In contract extension properties would need to store state on that object, dynamically. Now, if you come from working in dynamic languages this may seem silly to you because you can modify objects and definitions at will, however the .NET framework is not a dynamic framework, it's typed and defined, and security plays a big role in that.

So, by saying that extension properties are simply an extension of extension methods you are implying that the .NET framework should have the right to simply modify an object's IL at will. I think that would be a pretty clear violation of security because now the .NET framework would be acting in a malicious manner, abstractly speaking.

Please remember that Microsoft must solve problems on a different level than what we consume them. Until they come up with a solution that works well, why don't you use a very basic workaround. Build a static generic cache object that will store state in a dictionary and then in the extension method get and set against that cache and BAM you have an extension property.

So, in short (or maybe long) I think you might be able to see why Foo of type T isn't just building get_Foo(T) and set_Foo(T).

re: Why No Extension Properties?

Avi — Thu, 10 Nov 2011 20:24:48 GMT

Candid! We all do mistakes...

re: Why No Extension Properties?

Stephen — Thu, 15 Sep 2011 15:55:24 GMT

With the next release of Visual Studio (2011) and .NET 4.5 in preview, I got to wondering what the status of this feature is. I know that WPF is kind of deprecated in favor of HTML 5. But this would be useful in more things than just WPF (and for those not wanting to jump on the HTML 5 bandwagon, it would be great!)

Any chance the next release of Visual Studio will have a C# 4.5 in it? Will this feature be in it?

WPF is not deprecated. We have no plans to do extension properties. The majority of the development work is dedicated to getting asynchrony working and of course all the changes necessary to support a rich WinRT experience in C# and VB. We are not discussing ship vehicles or schedules at this time. -- Eric

re: Why No Extension Properties?

Chris Moschini — Mon, 04 Jul 2011 02:00:31 GMT

BitFlipper does a great job of designing extension properties, constructors, operators, and methods here:

channel9.msdn.com/.../257556-C-Extension-Properties

I propose that design be used in the next version of C#. It requires moving on from the existing implementation, but it's much more natural, and makes the path forward obvious.

re: Why No Extension Properties?

Matthew Brand — Tue, 29 Mar 2011 08:21:11 GMT

I would love to see extension properties, if only to pretty my code by getting rid of many brackets (), but understand the reasons why they are not in yet. C# keeps getting better with each version. Good work.

re: Why No Extension Properties?

shawn — Sun, 27 Mar 2011 18:42:42 GMT

With the rising popularity of fluent interfaces (including internally at Microsoft) it seems like extension properties would be more and more useful. From setting "properties" like IsRequired() in the new Entity Framework Code First fluent mappings, to being able to namespace ASP.NET MVC HTML Helpers (for example adding Html.Product.SomeProductRelatedHelper() where Product is an extension property on System.Web.Mvc.HtmlHelper), to the canonical Rubyesque 10.Days.Ago example, it seems like it would fill a missing gap in the language. Doing some searches it looks like there is a large demand for this, and I for one would love to see it!

re: Why No Extension Properties?

Chris Marisic — Wed, 19 Jan 2011 17:35:01 GMT

Eric, We can count on this for 5.0 right?

I wouldn't if I were you. - Eric

re: Why No Extension Properties?

mrjimmy — Thu, 29 Apr 2010 23:50:31 GMT

What about STATIC extension methods? It's very interesting there's no mention of it here as it's an oft-requested feature that would be extremely usefull.