Why No Extension Properties?

Why No Extension Properties?

Rate This
  • Comments 35


Good question.


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

  • 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 :-)

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


  • Frankly, for WPF, some automated way to generate property change notifications and/or propertyinfoof() would result in a much higher productivity increase than extension properties, IMO. So if they are the main potential beneficiaries of this feature, I would hope to see it after those other two rather than before.

    Side note: captchas are still acting weird. When I load a page, I see a new captcha (i.e. it's different from what was there last time I posted), but when I actually try to enter it when posting, I get the "code was invalid" error message; I have to reload the captcha image itself to get a "valid" one.

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

  • Can you elaborate any on the differing needs of WPF vs. the initial implementation?

    My current expectation as a C# programmer is that an extension property "Foo" of type T would be about (nearly? almost exactly?) the same as two extension methods: "T get_Foo(this SomeObject)" and "void set_Foo(this SomeObject, T value)".

    While I can understand the problems with making my "about the same as" statement working with the language, it's not clear how extension properties would/could be (significantly) different than extension methods.

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

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

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

  • 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

  • @Scott Schlesier,

    Could it possibly be taken one step further? I mean could the C# language become - in part, at least - an open-source project where the MS team people do what THEY can from what THEY think is necessary (on the gotta have / nice to have / bad idea basis), and the rest of the community does the rest, if they want it badly enough?

    The users can then purchase the "original" C# with VS/.NET and download the extensions for free, or for a price that looks reasonable from the average developer's salary (or average small consultancy business' income) viewpoint...

    Personally, I've got enough of ITIL/PRINCE2/SCRUM/etc. certifications to understand what the resource and financial restrictions are all about (and why, therefore, some features not only have to be cut, but also reviled as "not serving the needs of the customers" so that the team doesn't feel so bad about it :-) ), but one thing I never learned (and never will) is to like and appreciate restrictions (I can tolerate them for now: that's as much as you gonna get from me).

    I know we can do it now: no one is stopping us, but what I mean is some sort of approval, endorsement, certification, whatever, from Microsoft, saying, basically, "this extension is approved by the C# designers, can be downloaded from MSDN, and is guaranteed to work as well as the rest of the language", to calm down the nervous Nellies from the executive management who want everything legal and official. Would that be possible?

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


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


    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.

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

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

  • 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?

Page 1 of 3 (35 items) 123