Partager via

Why No Extension Properties?

  • Article

I'm frequently asked "you guys added extension methods to C# 3, so why not add extension properties as well?" 

Good question.

First, let me talk a bit about C# 3. Clearly the big feature in C# 3 was LINQ. In a sense we had only three features in C# 3:

  • everything necessary for LINQ -- implicitly typed locals, anonymous types, lambda expressions, extension methods, object and collection initializers, query comprehensions, expression trees, improved method type inference
  • partial methods
  • automatically implemented properties

The latter two were tiny compared to the items in that first bucket. On the design side, the syntax and semantics of both features are straightforward. On the implementation side, we already had the mechanisms in place to remove a call site; partial methods and conditional methods are pretty much the same thing behind the scenes. Auto props were also straightforward to analyze and generate code for. The testing burden was not particularly large for these features either.

The C# team was "the long pole" for the 2008 release of Visual Studio and the .NET Framework. By that I mean that if you took the amount of time required to do the work each team signed up for, given our level of staffing, blah blah blah, and made a pole proportionally long for each team in Developer Division, the C# pole would have been the longest pole. Which means that every other team in devdiv had slack in their schedule, but if we slipped our schedule a day, the new VS/CLR would also ship a day late. If any other team slipped a day, well, as long as that didn't make their pole longer than ours, they were still OK. Within the team, dividing up the work amongs the various development team members, the "long pole" work was the lambda binding and method type inference work, which was mine. So in a sense, every day that I was late, we'd slip the whole product that many days. (No pressure!)

Fortunately we have an excellent team here, we all supported each other very well through that release, picked up each other's slack when necessary, and delivered a quality release in plenty of time. My point is simply that unless a feature was either necessary for LINQ, or small and orthogonal and easy to cut if necessary (like the other two), it got cut immediately. There was no way we were going to risk slipping the entire product for any feature that was both complex and unnecessary.

It was of course immediately obvious that the natural companion to extension methods is extension properties. It's less obvious, for some reason, that extension events, extension operators, extension constructors (also known as "the factory pattern"), and so on, are also natural companions. But we didn't even consider designing extension properties for C# 3; we knew that they were not necessary and would add risk to an already-risky schedule for no compelling gain.

So now we come to C# 4.

As I'm fond of pointing out, the answer to every question of the form "why doesn't product X have feature Y?" is the same. It's because in order for a product to have a feature, that feature must be:

  • thought of in the first place
  • desired
  • designed 
  • specified
  • implemented
  • tested
  • documented
  • shipped to customers

You've got to hit every single one of those things, otherwise, no feature. 

When we started working on C# 4, we made a list of every feature request we'd heard of. It had hundreds of features on it. As I described last year, we categorized that list into "gotta have / nice to have / bad idea" buckets. Extension properties were in the "gotta have" bucket. We then looked at our available budget -- which was not so much measured in dollars as in available designers, developers, testers, writers and management multiplied by available time -- and determined that we did not have the resources to do more than about half the things in the "gotta have" bucket. So we cut half that stuff. Extension properties made it past that cut.

We then designed the feature. We had many hours of debate about the proposed syntax on the declaration side, how to call an extension property getter or setter "directly" as a static method, and so on. We came up with a syntax we could agree was acceptable, designed the semantics, wrote up a draft specification, and started writing code and test plans.

By the time the code was in reasonable shape -- not yet seriously tested, but usable and compliant with the spec -- we'd been having meetings with the WPF team. WPF developers were the assumptive primary consumers of extension properties. WPF already has a mechanism that resembles extension properties; it would be nice to unify that mechanism with our mechanism. Unfortunately, after taking a deep look at their real-world scenarios, we came to the disappointing conclusion that we had designed the wrong thing; this was not actually a feature that would solve their problems.

This is, admittedly, in a sense a failure of the design process. In retrospect, we should have gotten input and feedback from the primary customer much earlier. Had we done that then they could have either influenced the design to make something that would work for them, or we could have cut the feature without taking on the expense of writing spec, code and test plans.

But when you're in an unfortunate situation, you've got to decide to stop throwing good money after bad. Rather than take on the additional costs -- testing, documentation, shipping, and then maintenance of the feature for the rest of the life of the language -- in exchange for a feature that did not serve the needs of our customers, we cut the feature. At that point we did not feel confident that we had enough cycles remaining to redesign the feature the right way.

Therefore, sadly, no extension properties in C# 4. Perhaps in a hypothetical future version of C#.

Comments

  • Anonymous
    October 05, 2009
    oh man.. thats so bad.. I was expecting extension properties to be part of next ver of c#.... you will realize the value or importance of it only if you work with extension methods.. in last 6 months atleast 10 times I have thought why these guys(c# guys) didnt include exntesion properties... you ask your WPF team(i was missing it during my databindings) then you will realise its worth more than silly things(for me) like the partial methods.. hopefully you will get a big budget next time :-)

  • Anonymous
    October 05, 2009
    I can think of far more uses for extension operators and extension constructors - but maybe that's just my domain. I think the thing that gets me is that not everyone who uses .NET uses WPF.  In fact, I find when I have to put together a desktop app (my primary work is web-based), I use winforms because it's generally the simplest thing that solves the problem.  However, most of the time, I could care less about WPF (or WF, for that matter). Disappointing.

  • Anonymous
    October 05, 2009
    The comment has been removed

  • Anonymous
    October 05, 2009
    @Rick - So you really DO care about WPF and WF [if you COULD care less, you much have a level of caring which could be decreased - it is only if you could NOT care less that you would have no caring]. Just as an FYI, I have adopted the use of WF for almost all of the logic even in Winforms apps, once it becomes "comfortable" there are really some amazing capabilities that can easily be leveraged. @Pavel - I agree with you 100%. In fact, I am not sure extension properties really help databinding at all since they are not part of the intrinsic metadata of thye type itself.

  • Anonymous
    October 05, 2009
    The comment has been removed

  • Anonymous
    October 05, 2009
    @TheCPUWizard - Yes, I meant "could not care less".  Noticed it after posting, I had hoped that was clear by the context.  Didn't realize it needed clarification. I second J. Daniel Smith's request for elaboration, it would at least make an interesting article.

  • Anonymous
    October 05, 2009
    To me, the natural consumer of extension properties is fluent interfaces. Fluent nHibernate, fluent NUnit, home-grown fluent interfaces, etc. It's a real pain to have to remember where you do need parens (because it's an extension method) and when you don't. Here's hoping it makes the cut in a future version. And I'll also vote in favor of hearing the details -- it definitely would be an interesting article.

  • Anonymous
    October 05, 2009
    I don't understand how extension properties would be a good idea. Sure, they look cool and may get rid of some parenthesis, but i don't understand how something that looks like a member types (but it's actually static) isn't a bad idea. To be fair, I have no idea what extension properties would look like in the mind of the C# team.

  • Anonymous
    October 05, 2009
    This article makes it look as if the only customers that count are internal Microsoft customers.  I expect a lot of developers outside of the WPF team would have been very happy to have extension properties, I know I would.  What about the rest of your customers, especially those who actually pay money for your product? Sorry, I must have done a really exceptionally poor job of explaining myself, since you've completely and utterly misunderstood me. The WPF team is a few dozen people, tops. We don't design and implement language features for the convenience of a few dozen people, even if they are very nice people just across the plaza from us. That would be ludicrous. We design features for the WPF team's hundreds of thousands of customers. You know, the people who pay us money for the WPF designer, and then use it to make applications that they then sell to their customers. The WPF team members are the people who best understand the needs of those thousands of customers; when I say we're designing a feature "for the WPF team", it's not for their internal development team, it's for their customers. Is that now clear? -- Eric

  • Anonymous
    October 05, 2009
    The comment has been removed

  • Anonymous
    October 05, 2009
    You mention above  : "and determined that we did not have the resources to do more than about half the things in the "gotta have" bucket. So we cut half that stuff." So what happens to the half of the features that were cut for C# 4.0 - do they then become the absolutely must have top 5or 6 things for C# 5.0 ? Or do you again start from scratch for C# 5.0 ? Sure , things will change between now and the time for drawing up the spec for C# 5.0 comes around, but keeping the "dropped features from 4.0" as top priority for 5.0 will lend continuity to the process and also help re assure developers that if not in this version then atleast the next. great posts , by the way. Thanks.

  • Anonymous
    October 05, 2009
    @Eric, What I got from your post was the feature didn't meet the needs of WPF, but presumably it did address non-WPF needs.  I suspect that there are still many more C# developers out there who are not using WPF than are using WPF.  It seems the non-WPF folks missed out because the WPF team couldn't use the implementation of extension properties. I'm guessing the key is that the extension properties were intended to have been used in most of not all WPF applications, but outside WPF it would merely be an occaisionally used bit of syntactic sugar. @Denis, Mono is already the open source alternative.  Though they have their hands pretty full just keeping up with the core features so far.  Extending libraries is one thing, and I love that MS is embracing OSS more and more.  But, I think getting acceptance for non-standard extensions to the C# language will be very difficult.

  • Anonymous
    October 05, 2009
    It would be very interesting to be able to see the list of features that were considered for C#3 in the gotta have/nice to have/bad idea buckets, maybe along with reasoning for a few of them, to see the behind-the-scenes thought processes...

  • Anonymous
    October 05, 2009
    Thank you. Every time you explain why C# doesn't do something or does it a certain way, any frustration with the fact quickly evaporates and turns into understanding. This blog always makes me feel better about my most favourite language ever, C#. And I'm wishing MSDN docs linked to your posts whenever possible, because to me, answering the "why"s is no less important than answering the "how"s.

  • Anonymous
    October 06, 2009
    Eric, what about static extension methods? What I mean by that is extension methods that can apply to a type like static methods. For example, you could have an extension method Yesterday that you could call on DateTime. Obviously, you could create a DateTimeUtil but other coders working on the same project might not now that it exists! I know it would have been useful to me in a couple of cases. Has it been considered? If yes, why was it rejected? Could it be added in a future version?

  • Anonymous
    October 06, 2009
    Cool - I've actually often found myself wondering lately why there are no extension properties. It's a little disappointing, but really nothing to get bent out of shape over.  I don't see why so many people need to complain.  There's nothing you'd be able to do with extension properties that you can't already do with extension methods, except for having a slightly cleaner interface.  Properties ARE methods, fundamentally, they're just syntactic sugar for a getter and setter. I'm actually more interested in knowing what was so important for the WPF team (and its customers) that pushed the feature into the "must have" bucket in the first place.

  • Anonymous
    October 06, 2009
    From what I gather, the primary benefit of a property over a method is not that you don't have to type (), it's that the designers (such as WPF, windows forms, etc) can bind to properties but not to methods.  It sounds like Eric is saying that due to some as-of-yet unexplained reason, their design did not allow this binding to work as expected.  If it doesn't help with that scenario, then all that's left is the syntactic sugar letting you omit the (), which is not an overly useful language feature and is sure to get in the way of designing a better implementation later.

  • Anonymous
    October 06, 2009
    'In retrospect, we should have gotten input and feedback from the primary customer much earlier...' This is starting to sound a bit like Agile ;)

  • Anonymous
    October 06, 2009
    @Pavel You wrote that an automatic way to do generate property change notifications would be the more interesting feature.  I wrote something to do exactly that, here: http://activesharp.codeplex.com/ It is usable from standard .NET code, and it works entirely at runtime (no codegen).

  • Anonymous
    October 07, 2009
    The problem with automatic property change notifications is when I have a property like this: string FullName { get { return FirstName + " " + LastName; } } Somehow a change to either FirstName or LastName has to notify subscribers that FullName has also changed. You would have to be able to annotate FullName to indicate what proprties to notify changes for.

  • Anonymous
    October 07, 2009
    @Gabe, Actually my SmartData architecture addresses exactly that type of situation. An example (very basic) implementation is on CodePlex [http://smartdata.codeplex.com].  Please feel free to contact me directly for more information: david "dot" corbin "at" dynconcepts "dot" com.

  • Anonymous
    October 07, 2009
    The comment has been removed

  • Anonymous
    November 14, 2009
    Eric, thanks for sharing that story. I think everybody would love to have extension properties. In my opinion, properties are different members from methods in a sense that they highly need to be discoverable. Databinding is of course almost entirely based on properties and properties metadata, in WPF but also in any other interfaces (winforms, asp.net). And if it's been a problem for WPF, I think there are good chance that we all meet the same issues one day. Personnaly, I prefer having to wait the best possible feature.

  • Anonymous
    December 10, 2009
    It's very saddening to see extension properties meet the axe, I see very little in code that looks dumber than if(session.Is().Not.Null) but it's nice to see Microsoft be open about the reason for something than sometimes that it feels features get the axe with little to not explanation.

  • Anonymous
    April 28, 2010
    Couldn't extensions just be defined when you prefix a variable, method, or property with a class in perentesis? (Person) private int height;

(Person) public Person BestFriend {    get;    set; }

(Person) public static void Person(string firstName, string lastName) {...} Seems that this would make extensions a lot simpler, (without the extra 'this' parameter) and would make properties and variables extension-able.  Newbie programmer's thoughts; is this confusable with some other C# format?

  • Anonymous
    April 29, 2010
    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.

  • Anonymous
    January 19, 2011
    Eric, We can count on this for 5.0 right? I wouldn't if I were you. - Eric

  • Anonymous
    March 27, 2011
    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!

  • Anonymous
    March 28, 2011
    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.

  • Anonymous
    July 03, 2011
    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.

  • Anonymous
    September 15, 2011
    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

  • Anonymous
    November 10, 2011
    Candid! We all do mistakes...

  • Anonymous
    November 24, 2011
    The comment has been removed

  • Anonymous
    March 19, 2012
    > 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 ... :(

  • Anonymous
    May 15, 2012
    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)