views:

505

answers:

4

I recently asked this question: http://stackoverflow.com/questions/638463

Marc Gravell answer was perfect and it solved my problem. But it gave me something to think about...

If and Extension method must be placed on a Static Class and the method itself must be static, why can't we create a static Extension method?

I understand that the parameter marked as "this" will be used to allow access to an instance of the object we are extending. What I do not understand is why can't a method be created to be static... it just seems to me that this is a senseless limitation...

My question is: Why can't we create an extension method that will work as a static Method?

+3  A: 

Because that feature doesn't exist in C#.

As a workaround, static methods can be implemented in another class and called through that class to provide the added functionality.

For example, XNA has a MathHelper class which ideally would have been static extensions to the Math class.

The community is asking if we think it's a good idea for C# 4.0

Ben S
Re your assertion: that is the **community** asking the community. I don't think Max Payne represents Microsoft in this matter.
Marc Gravell
Good point, edited post.
Ben S
Fair enough ;-p Your point about MathHelper is very valid - I just wonder whether it is compelling *enough* to make the cut.
Marc Gravell
I think too many developers are used to these "Helper" static classes. I would be surprised if the C# designers agreed to sully static methods to save people from typing Helper a couple of times.
Ben S
Remember that a one of the big benefits of extension methods is to do away with the need for Helper static classes.
Dustin Campbell
@Dustin; arguably, it is more to enable fluent API usage, so that you have foo.Bar().Blop(), not Blop(Bar(foo)) - but this simply doesn't apply with static.
Marc Gravell
+6  A: 

I expect the real answer is simply: there wasn't a good use-case. For instances, the advantage is that it enables a fluent-API over existing types (that don't themselves provide the logic) - i.e.

var foo = data.Where(x=>x.IsActive).OrderBy(x=>x.Price).First();

which enables LINQ:

var foo = (from x in data
           where x.IsActive
           order by x.Price
           select x).First();

With static methods, this simply isn't an issue, so there is no justification; just use the static method on the second type.

As it is, extension methods are not properly object orientated - they are a pragmatic abuse to make life easier at the expense of purity. There was no reason to dilute static methods in the same way.

Marc Gravell
Static extension methods could rid us of all those "Helper" classes filled with static methods. See the feedback like for a use-case of this.
Ben S
A: 

First of all you would have to add yet another syntax to indicate you want to extend the static methods of the existing type. When extending syntax you really need a very good reason to do so.

Lets imagine I have a class called MyExts which allow me to add extension methods to MyClass. Why would:-

MyClass.DoSomethingExtra();

be better than

MyExts.DoSomethingExtra();

?

AnthonyWJones
The whole point of static extensions would be to be able to call MyClass.DoSomethingExtra(), but having defined it in MyExts to extend MyClass.
Ben S
Yes I understand that, my question back is WHY would you want to do that? Its not like you don't have to first understand they are coming from MyExts because you'd still have to place a using for it in the file.
AnthonyWJones
+1  A: 

My thinking would be for compatibility - if you suddenly made all static methods extension methods with the need for the this operator you could inadvertently break code which now is overriding a normal method with an extension method.

The this parameter allows control and thus doesn't break compatibility.

Just an idea though.

Robert MacLean