6

I found the "Extension method" concept of C# just wonderful. It enables us to do things like:

And The coolest thing about it IMHO is that adding a method doesn't break backward compatibility.

However, I found almost no extension methods in the .NET BCL. And it's very common that, I see a static method and extension methods come in mind.

When the BCL was designed, extension methods were not there. But why are they not converted to extension methods now? Specially when it does break backward compatibility? Any reasons?

Community
  • 1
Gulshan
  • 9,402
  • 10
  • 58
  • 89
  • 1
    I would like to write `a.Round()` instead of `Math.Round(a)` and `a.Pow(b)` instead of `Math.Pow(a,b)`. But `Math.Max(a,b)` is ok. – Gulshan May 19 '11 at 11:31

2 Answers2

10

The point of extension methods is to allow you to add features to classes you cannot modify or inherit from. For example, if in a very specific case you want to display an integer as a money,

  • either you create a static class HelloWorld with the method public static string DisplayIntAsMoney(int amount) and use it like HelloWorld.DisplayIntAsMoney(5990) to obtain "$US 59.90",
  • or you create an extension method and use it like 5990.AsMoney().

The first one is ugly. The second one is ugly too, but much shorter.

But extension methods don't have to be used everywhere to do everything. This is a tool. Don't use it abusively.

For example, if you've written a library with a class and you want to add features to it to use in another project, you have two choices:

  • Use an extension method,

  • Return to the former library and modify it by providing an inherited class which provides the feature or by adding the feature directly to the class.

The first one is ugly. Very ugly. It also forces you to violate the DRY principle, since you'll probably rewrite the same extension method again and again in many projects which will use the same library. The second one on the other hand let you provide more features without breaking backward compatibility (at least in the case you create an inherited class).

This being said, extension methods are pretty useful in two cases:

  • When you need to extend classes you cannot modify,

  • When you need to provide common features without having to modify the existing huge codebase or you have to provide features that may be turned on and off by adding or removing references to your project.

The first reason doesn't apply to .NET BCL. Microsoft has the source code. Microsoft can modify it directly, instead of using extension methods. It's exactly what happens actually.

The second reason applies to .NET codebase. But, wait, aren't they doing exactly this thing with LINQ, Reactive Extensions, etc.?

Edit following your comment:

There are four reasons why we have Math.Round(a) instead of a.Round():

  • Math.Round existed before extension methods appeared, and it's never a good idea to rewrite an existing API just for the sake of rewriting, breaking all legacy source code.

  • Having extension methods for Round or Pow but static methods for Max is just too confusing, especially when you don't use the API too often. Actually, I know that if I want something mathematical, I have to type Ma, autocomplete, and start to type the name of the method. With your approach, I would sometimes mistake by starting to type Ma, searching for the method, discovering that the method does not exist, recalling that it might be an extension method, removing Math. then starting to type in a way to obtain autocompletion for the extension method.

  • Math methods belong to System namespace. This namespace is declared in nearly every file of every project. This would mean that you'll have Round, Floor etc. autocompletion every time you enter an integer followed by a dot. It's just too annoying. Having too many methods in intellisense not only makes it difficult to find the good one, but it also decreases performance on slow computers.

  • float, double and int do not inherit from the same type. If LINQ extension methods are commonly associated with IEnumerable or some base types, it is impossible to do it with Math methods. The only way is to write code for every type, which is probably not the most elegant approach. With static methods, there are also overloads, but they are much shorter to write and easier to understand.

Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
  • I was surprised to discover that the .Net string class is sealed. One of my very first java lessons involved inheriting from string and adding some useless functions. When I needed to do this in .Net I ended up using extension methods. But I can't help but wonder if inheritance wouldn't have been a better solution. What if I wanted to create several different permutations of the string class used for different situations? If that were the problem would I have ended up having been flooded by extensions methods that do no not apply for a particular situation? – Tjaart May 19 '11 at 08:14
  • @Tjaart: That's why you have the concept of namespaces. You just implement every permutation you would have into a different namespace (and potentially in a different library), and then only include the namespace (library) you need for your specific situation. – fretje May 19 '11 at 08:21
  • I guess this could work, but wouldn't this be misusing namespaces? I always thought of namespaces as broader categories. – Tjaart May 19 '11 at 09:04
  • 2
    @Tjaart Java's `String` has been final since at the very least 1.0.2 (see http://www.aquaphoenix.com/ref/jdk1.0.2_api/java.lang.String.html), so how did you derive from String? Or were you using an alternative JDK? – yatima2975 May 19 '11 at 10:20
  • I actually think it was an alternative JDK. My bad. – Tjaart May 19 '11 at 10:24
  • In the second example, wouldn't it be more correct to inherit the functionality from the class and then add to it? or even better, use decorators for that? – Ziv May 19 '11 at 10:45
  • Probably my "almost every time" confused you. So, I have edited for clarification. I'm also against abuses of extension methods. My concern was not "when extension methods are appropriate". Rather I am talking about those BCL methods which are __already chosen to put as static in a different static class other than the basic class__ by microsoft and very much appropriate to be modified to the extension methods. An example can be many(not all) methods in `System.Math`. I think I am clearer now. – Gulshan May 19 '11 at 11:24
  • @Gulshan: I see. Well, `Math` methods are better static. I edited my answer to explain why. I'm sure that there are other examples when it's much less obvious. In all cases, extension methods are already used a lot (LINQ and Rx being the most popular), and I'm pretty sure that they will be used even more in future; of course, this doesn't mean that Microsoft will rewrite existing code just to use extension methods even in cases where the code will become better. – Arseni Mourzenko May 19 '11 at 12:07
  • @Tjaart: "wouldn't this be misusing namespaces": Don't think so. E.g. your general string extension methods could go into `mybusiness.stringextensions`, while extensions for easily parsing html fit into a `mybusiness.stringextensions.html` namespace (and they can even be split over different assemblies). – fretje May 19 '11 at 12:22
  • Let me tell you a special extension method feature that I've already called the coolest. It does not break backward compatibility. It actually means, if you use extension methods, you can still write `Math.Round(a)`. But you can use more convenient `a.Round()` too. So, your first two reasons are invalid. Your third reason also applies to `IEnumerable`. But was it a problem to you while coding? And I am not clear whether the last one is a reason. To make a method extension method, you have to add just a single `this` to it in the implementation code. Overloading is no problem here. – Gulshan May 19 '11 at 12:29
  • @Gulshan: so your question is in fact: "why Microsoft had not added extension methods in addition to static methods of `Math`?". The answer is easy: because Microsoft developers have better things to do, because it's not extremely useful and finally because if you really need it, you can do it yourself and post to CodePlex. – Arseni Mourzenko May 19 '11 at 16:52
  • So, no technical reason? – Gulshan May 20 '11 at 03:54
3

My guess is that the CLR team has bigger fish to fry then go back and redo old designings. Unfortunately once something gets into the .Net framework it's there for good. If they could turn back time I bet there's a bunch of stuff they'd do different including the use of out/ref parameters, the use of certain interfaces and burning a bunch of base classes (MarshalByRef anyone) :)

Adding extensions methods for everything would make the framework a bit more cluttered. As you say you can pretty easily add extension methods for stuff yourself, just reference the old static methods

Homde
  • 11,104
  • 3
  • 40
  • 68
  • I did not mean "everything". I'm sorry my wording was confusing. I tried to say- there are many places where extension methods would have been appropriate and will not break backward compatibility. – Gulshan May 19 '11 at 11:27