This question already has answers here:
"this" in function parameter
(5 answers)
Closed 9 years ago.
I want to understand how extension method works?Can we define extension methods in non static classes?
*
Why do we put extension methods inside static class?
*
According to MSDN,
**Their first parameter specifies which type the method operates on, and the parameter is preceded by the this modifier. Extension methods
are only in scope when you explicitly import the namespace into your
source code with a using directive.
**
What is the role of this operator here and how does it associates that extension method to that argument?
No, you can't define an extension method on a class that is not static.
The this is syntactic sugar that allows to call your static extension method on an instance. But at the end of the day, an extension method is nothing more than a static method in a static class.
So basically:
var test = myInstance.MyExtensionMethod();
is the same as
var test = MyExtensionClass.MyExtensionMethod(myInstance);
They are 4 requirements for method to be an extension method:
It has to be declared in static class
It has to be static (which actually is always true if the first one is met)
It has to be public
It has to have first parameter marked with this keyword
So you can't define extension method in non-static class.
Whole Extension Method functionality is some kind of syntax sugar. Following extension method declared on MyClass:
// The following extension methods can be accessed by instances of any
// class that is or inherits MyClass.
public static class Extension
{
public static void MethodA(this MyClass myInterface, int i)
{
Console.WriteLine
("Extension.MethodA(this IMyInterface myInterface, int i)");
}
}
can be called in two ways:
var myClassObject = new MyClass();
Extension.MethodA(myClassObject);
Or
myClassObject.MethodA();
However, the second one will be transformed into the first one by compiler anyway.
What is the role of this operator here and how does it associates that
extension method to that argument?
In this context this is not an operator, it is a modifier. It could have been called something else, it has no relation to this object which refers to the current object within a normal method call.
The role of this modifier is to tell the compiler that this is actually an extension method and not a standard static method, so that it will not complain when you call it in a way which looks like an instance method call, although it is not.
No, extension methods have to be in a static class, that's just the rule. It could have been possible to allow extension methods to be defined anywhere, but to make it easier to find them they are not allowed to be buried inside classes with a lot of other code.
The this keyword is used on the first parameter of an extension method to specify that it is an extension method.
(The internal implementation of a regular method also has a reference to the object as a first parameter, so what the compiler does with extension methods is just to add them to the other methods in the class.)
Related
This question already has answers here:
When should one prefer Kotlin extension functions?
(4 answers)
Closed 5 years ago.
I'm writing Kotlin code and one the features it has is extension methods, which are effectively the same as normal functions except the syntax you use looks like an instance method call.
Normal function
fun blah(x: Int) { println(x) }
val f = blah(1)
Extension method
fun Int.blah() { println(this) }
val f = 1.blah()
As far as I understand, C# extension methods work similarly.
In principle, literally any non-nullary function could be written as an extension method by moving the type of the first parameter to the left of the function name and adjusting the function body and call sites accordingly (as in this example).
Should I write all my functions as extension methods, then? None of them? What principle should I use to decide what functions to write normally, and which to write as an extension method of one of the inputs?
https://kotlinlang.org/docs/reference/extensions.html#extensions-are-resolved-statically
Extensions are resolved statically
Extensions do not actually modify classes they extend. By defining an
extension, you do not insert new members into a class, but merely make
new functions callable with the dot-notation on variables of this
type.
We would like to emphasize that extension functions are dispatched statically, i.e. they are not virtual by receiver type
So writing all of your functions as extension methods wouldn't be a good approach because they are dispatched statically. This takes away the ability to override them e.g. in derived classes.
It is more like a design choice when you make a extension function or a "normal" function.
I would recommend you the following:
Whenever you have a function which you would write as an Utility-function with an Utility-class like StringUtil.isNullOrEmpty(String), use extension functions. Use the rest as "normal" functions.
Also read the Kotlin's motivation to create Extensions:
https://kotlinlang.org/docs/reference/extensions.html#motivation
You write extensions when you do not have access of source code. In Java, you write utility classes.
public final class BarUtility {
public static int foo(Bar i, int j){
return i.value + j;
}
}
BarUtility.foo(bar, 1);
In Kotlin, you write extensions method.
fun Bar.foo(i: Int): Int = value + i
bar.foo(1)
In C#, it is the same but you also use it for interface method implementation. (Kotlin allows interface method implementation.)
There is no fixed rule, but you shouldn't write all of your normal functions as extension methods.
They are primarily used for two things:
Extending types that you don't have direct control over. A common example in C# is the ForEach() function that extends IEnumerable (basic types for lists etc.) with a method to apply an action to all items:
public static void ForEach<T>(this IEnumerable<T> enumeration, Action<T> action)
{
foreach (T item in enumeration)
{
action(item);
}
}
Helper functions that simplify common calls to your own classes, but don't warrant an own method in your class or you don't want be part of your API.
I knew the first half part of the magic. Assume I have:
public class Foo {}
public class static FooExt
{
public static void M(this Foo f) {}
}
When I invoke foo.M() the compiler changes it to FooExt.M(foo).
But how about the inheritance? For example:
public class Bar : Foo {}
public class static BarExt
{
public static void M(this Bar b) {}
}
When I invoke bar.M() will it call FooExt.M() or BarExt.M()? In fact I tested it and the answer is BarExt, but why? What happens when I call wow.M() if I have another Wow : Foo but no WowExt.M()?
The compiler will look for the extension method whose arguments most closely match those at the invocation site. If you have a variable of type Bar then the BarExt extension would be used, since Bar is more specific a type than Foo, and therefore matches more closely than the alternative method that takes a Foo instance. This really is not very different from how ambiguous method overloads are resolved.
It is worth noting that this code will call FooExt.M():
Foo bar = new Bar();
bar.M();
This is because extension methods are not virtual. Since the variable you are invoking the method on is type Foo, the Bar version of the extension method will not even be considered. Binding of extension methods happens entirely at compile time.
In the second case you indicated (invoking the extension method on a variable of type Wow), the FooExt.M() method would be used, since there is nothing that matches better.
I tested it and the answer is BarExt, but why?
Because the compiler will choose the extension method that "best fits" the call. Since there is a method that takes a Bar directly, that one is chosen.
What happens when I call wow.M() if I have another Wow : Foo but no WowExt.M()?
Again, it will choose the extension that "best fits" the usage. Since there is no method that takes a Wow, but one that does take it's parent class Foo it will choose FooExt.M()
Remember that extension methods are really just syntactic sugar for static method calls, so the same rules apply to them as "normal" method resolution.
When resolving extension methods, the most specific type match will be selected. In your first case, BarExt.M() is the most specific (targets Bar rather than Foo).
In the second case, there is no Wow extension so the most specific match would be FooExt.M().
Can someone explain to me why in the following the 3rd invocation of DoSomething is invalid?
( Error message is "The name 'DoSomething' does not exist in the current context" )
public class A { }
public class B : A
{
public void WhyNotDirect()
{
var a = new A();
a.DoSomething(); // OK
this.DoSomething(); // OK
DoSomething(); // ?? Why Not
}
}
public static class A_Ext
{
public static void DoSomething(this A a)
{
Console.WriteLine("OK");
}
}
Extension methods can be invoked like other static methods.
Change it to A_Ext.DoSomething(this).
If you're asking why it isn't implicitly invoked on this, the answer is that that's the way the spec was written. I would assume that the reason is that calling it without a qualifier would be too misleading.
Because DoSomething takes a parameter.
DoSomething(a) would be legal.
Edit
I read the question a bit wrong here.
Since your calling it a a normal static method, and not a extension method, you need to prefic with the class name.
So A_Ext.DoSomething(a); will work.
If you call it like a normal static method, all the same rules apply.
Your second variant works because B inhetits A, and therefore you still end up calling it as an extension method, but the third does not.
sorry about the first version above that does not work. I'll leave it to keep the comment relevant.
Extension methods are still static methods, not true instance calls. In order for this to work you would need specific context using instance method syntax (from Extension Methods (C# Programming Guide))
In your code you invoke the extension
method with instance method syntax.
However, the intermediate language
(IL) generated by the compiler
translates your code into a call on
the static method. Therefore, the
principle of encapsulation is not
really being violated. In fact,
extension methods cannot access
private variables in the type they are
extending.
So while normally, both syntaxes would work, the second is without explicit context, and it would seem that the IL generated can't obtain the context implicitly.
DoSomething requires an instance of A to do anything, and without a qualifier, the compiler can't see which DoSomething you need to invoke. It doesn't know to check in A_Ext for your method unless you qualify it with this.
How the C# compiler implement extension methods?
The process is exactly the same as overload resolution:
Func(myObject);
The compiler checks all functions named "Func" and tries to match the static type of myObject to the parametrs (possibly using conversions, upcasting to base class). If it succeeds, then calls the appropriate function.
If you realize that you can call extensions methods "in a normal way", then it clears up:
static class MyExtensions
{
public static void MyFunc(this string arg)
{
// ...
}
}
string a = "aa";
MyExtensions.MyFunc(a); // OK
a.MyFunc(); // same as above, but nicer
For the given type (here string), the compiler just looks for all static functions with "this" modifier on the first argument and tries to match the static type on the left of the . (in this example "a") with the parameter type in the function.
Instance methods of a class have a hidden argument. An example:
class Example {
public void Foo(int arg) {}
}
actually looks like this when the JIT compiler is done with it, converted back to C# syntax:
static void Foo(Example this, int arg) {}
That hidden argument is the reason that you can use this in an instance method. The JIT compiler figures out the argument to pass from the object reference you provide to call the Foo method.
As you can tell, it is now a very short hop to an extension method.
The compiler first looks in the base class for a function matching the signature of the function. If it can't find it than it looks for an extension. If an extension has the same signature as a base class method than the base class method is called instead.
This might help:
Extension Methods
This question already has answers here:
Can I add extension methods to an existing static class?
(18 answers)
Closed 2 years ago.
According to Microsoft, "Extension methods are a special kind of static method, but they are called as if they were instance methods on the extended type".
Is there a way to add an extension method that it called as if it was a static method? Or to do something else that has the same effect?
Edit:
By which I mean "called as if it was a static method on the extended class".
Sorry for the ambiguity.
According to Microsoft, "Extension methods are a special kind of static method, but they are called as if they were instance methods on the extended type".
Yes, extension methods are static methods. They can all be called in the normal way as static methods, as extension instance methods on the type they "extend", and they can even be called as extension methods on a null reference.
For example:
public static class Extensions {
public static bool IsNullOrEmpty(this string theString) {
return string.IsNullOrEmpty(theString);
}
}
// Code elsewhere.
string test = null;
Console.WriteLine(test.IsNullOrEmpty()); // Valid code.
Console.WriteLine(Extensions.IsNullOrEmpty(test)); // Valid code.
Edit:
Is there a way to add an extension method that it called as if it was a static method?
Do you mean you want to call, for example, string.MyExtensionMethod()? In this case, no, there is no way to do that.
Extension methods are static methods. You don't need to do anything.
The only thing that distinguishes an extension method from any other static method is that it can be called as if it were an instance method in addition to being called normally as a static method.