views:

476

answers:

3

I want to hide extension methods included in the .NET or ASP MVC framework by mine.

Exemple

public static string TextBox(this HtmlHelper htmlHelper, string name)
{
   ...
}

Is it possible? i cant use the override or new keyword.

+12  A: 

Extension methods cannot be overriden since they are not instance methods and they are not virtual.

The compiler will complain if you import both extension metod classes via namespace as it will not know which method to call:

The call is ambiguous between the following methods or properties: ...

The only way around this is to call your extension method using normal static method syntax. So instead of this:

a.Foo();

you would have to do this:

YourExtensionMethodClass.Foo(a);
Andrew Hare
+1 - Good point about the ambiguity, I forgot about that.
James Black
Well as Eric notes it's not importing two different matching extension methods, it's importing them on the same level of nesting.and Im sure he's talking about overriding the behaviour of one method with the behaviour of a different and not about polymorphic behaviour
Rune FS
+3  A: 

Extension methods are basically just static methods so I don't know how you can override them, but if you just put them in a different namespace then you can call yours instead of the one you want to replace.

But Matt Manela talks about how instance methods have precedence over extension methods: http://social.msdn.microsoft.com/forums/en-US/csharplanguage/thread/e42f1511-39e7-4fed-9e56-0cc19c00d33d

For more ideas about extension methods you can look at http://gen5.info/q/2008/07/03/extension-methods-nulls-namespaces-and-precedence-in-c/

Edit: I forgot about the ambiguity issue, so your best bet is to try not including the extension methods you want to replace. So, you may need to not use the 'using' directive but just put in the entire package name of some classes, and this could solve the problem.

James Black
+11  A: 

You can do this, in a sense. But I should start by talking briefly about the basic design principle of overload resolution in C#. All overload resolution is, of course, about taking a set of methods with the same name and choosing from that set the unique best member to call.

There are many factors involved in determining which is the "best" method; different languages use a different "mixture" of factors to figure this out. C# in particular heavily weights "closeness" of a given method to the call site. If given the choice between an applicable method in a base class or a new applicable method in a derived class, C# takes the one in the derived class because it is closer, even if the one in the base class is in every other way a better match.

And so we run down the list. Derived classes are closer than base classes. Inner classes are closer than outer classes. Methods in the class hierarchy are closer than extension methods.

And now we come to your question. The closeness of an extension method depends on (1) how many namespaces "out" did we have to go? and (2) did we find the extension method via "using" or was it right there in the namespace? Therefore you can influence overload resolution by changing in what namespace your static extension class appears, to put it in a closer namespace to the call site. Or, you can change your "using" declarations, to put the "using" of the namespace that contains the desired static class closer than the other.

For example, if you have

namespace FrobCo.Blorble
{
  using BazCo.TheirExtensionNamespace;
  using FrobCo.MyExtensionNamespace;
  ... some extension method call
}

then it is ambiguous which is closer. If you want to prioritize yours over theirs, you could choose to do this:

namespace FrobCo
{
  using BazCo.TheirExtensionNamespace;
  namespace Blorble
  {
    using FrobCo.MyExtensionNamespace;
    ... some extension method call
  }

And now when overload resolution goes to resolve the extension method call, classes in Blorple get first go, then classes in FrobCo.MyExtensionNamespace, then classes in FrobCo, and then classes in BazCo.TheirExtensionNamespace.

Is that clear?

Eric Lippert
+1 This is a much better answer :)
Andrew Hare