I was just curious to know how Extension methods are hooked up to the Original class. I know in IL code it gives a call to Static Method, but how it does that and why dosen't it break encapsulation.
They don't "hook up".
The Visaul Studio IDE just makes it look like it does by showing them in the intellisense lists.
The compiler "knows" how to deal with the references in order to make the right method calls with the correct parameters.
This is simply syntactic sugar - the methods are simply static methods on a separate static class. Using the this modifier lets the compiler "know" to add the ExtensionAttribute to the class to mark it as an extension method.
Since extension methods do not in fact change the class and can only access public members on it, encapsulation is retained.
From MSDN:
Extension methods are a special kind of static method, but they are called as if they were instance methods on the extended type.
(emphasis mine)
Extension methods are specified by putting the this keyword in front of the first parameter of a static method:
public static void SomeExtension(this string s)
{
...
}
That is just syntactic sugar for decorating the method with System.Runtime.CompilerServices.ExtensionAttribute:
[Extension]
public static void SomeExtension(string s)
{
...
}
When the compiler sees that attribute, it knows to translate the extension method call to the appropriate static method call, passing the instance as the first parameter.
Since the calls are just normal static method calls, there is no chance to break encapsulation; the methods, like all static methods, only have access to the public interfaces of the extended types.
Extension methods are just syntactic sugar, they are just static methods. You are only able to access public fields or properties in them, just like normal static methods.
The key ingredient is that an instance method of a class isn't fundamentally different from a static method. With one small detail, they have a hidden argument. For example, the String.IndexOf(char) method actually looks like this to the CLR:
public static int IndexOf(string thisRef, char value) {
// etc...
}
The thisRef argument is what supplies the string reference whenever you use this in your code or access a member of the class. As you can see, it is a very small step from an extension method to an instance method. No changes were necessary in the CLR to support the feature.
One other minor difference is that the compiler emits code that checks if this is null for an instance method but does not do so for an extension method. You can call an extension method on a null object. While that might look like a feature, it is actually a restriction induced by the extension method not actually being a member of the class.
Internally, the CLR keeps a list of methods for the class, the MethodTable. Extension methods are not in them, preventing the compiler from emitting the callvirt IL instruction, the 'trick' that it uses to get the cheap null check. Explicitly emitting code to make the null check would have been possible but they elected not to do so. Not quite sure why.
Another automatic consequence of this is that an extension method cannot be virtual.
I think you should have a look at http://go.microsoft.com/fwlink/?LinkId=112388
Related
As part of my application I have a function that receives a MethodInfo and need to do specific operations on it depending if that method is "Extension Method".
I've checked the MethodInfo class and I could not find any IsExtension property or flag that shows that the method is extension.
Does anyone knows how can I find that from the method's MethodInfo?
You can call the IsDefined method on the MethodInfo instance to find this out by checking to see if the ExtensionAttribute is applied to the method:
bool isExtension=someMethod.IsDefined(typeof(ExtensionAttribute),true);
Based on
F# extension methods in C#
it seems there is an attribute on the compiled form. So see if the method has this attribute:
http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.extensionattribute.aspx
This looks very similar to an earlier question, might be worth a look. The suggestion there was to look for classes and methods with the ExtensionAttribute which sounds like what you are after.
If you know you are getting a MethodInfo from an instance, you can easily check if the method is static. Extension methods are just syntactic sugar and get transformed into static method calls passing in the instance.
Doesn't the compiler switch all extension methods into static method calls at compile time?
myList.First();
becomes
Enumerable.First(myList);
If this is the case, then there are no extension methods in the .net runtime (where you are reflecting).
This question already has answers here:
Why are extension methods only allowed in non-nested, non-generic static class?
(3 answers)
Closed 9 years ago.
I understand that C# extension methods must be static. What I don't understand is why these extensions can't be defined in non static classes or generic ones?
Update: I am interested in the reason behind this design decision.
This is more of an observation than an answer, but...
When you call an instance method, a reference to the object you are calling is pushed onto the stack as the first argument in your method call. That first argument is "this" and is done implicitly.
When you define an extension method, you explicitly define a "this" as the first argument.
Is it possible that method resolution would be confusing if you could define extension methods and instance methods in the same class i.e. defining methods with the same name and, in effect, the same parameters when the "this" parameter is included.
Take a look to this piece of the .NET C# specification:
When the first parameter of a method includes the this modifier, that
method is said to be an extension method. Extension methods can only
be declared in non-generic, non-nested static classes. The first
parameter of an extension method can have no modifiers other than
this, and the parameter type cannot be a pointer type.
And this fragment from Jon Skeet's answer:
It's not clear to me why all of these restrictions are necessary -
other than potentially for compiler (and language spec) simplicity. I
can see why it makes sense to restrict it to non-generic types, but I
can't immediately see why they have to be non-nested and static. I
suspect it makes the lookup rules considerably simpler if you don't
have to worry about types contained within the current type etc, but I
dare say it would be possible.
Because the spec says so... Now there are probably good reasons why they wrote the spec this way.
The reason why they can't be declared in generic classes is quite obvious: given the way extension methods are called, where would you specify the type argument for the class?
The reason why it must be a static class is less obvious, but I think it makes sense. The main use case for static classes is to group helper methods together (e.g. Path, Directory, ProtectedData...), and extension methods are basically helper methods. It wouldn't make sense to be able to create an instance of Enumerable or Queryable, for example.
What is the difference between Extension Methods and Methods in C#?
I think what you are really looking for is the difference between Static and Instance Methods
At the end of the day Extension methods are some nice compiler magic and syntactic sugar that allow you to invoke a Static method as though it were a method defined on that particular class instance. However, it is NOT an instance method, as the instance of that particular class must be passed into the function.
ExtensionMethods : Let you define set of methods to a class without subclassing another benefit over inheritance.
Methods : They are used for implementation of operation defind for the the class.
See example of Extension Methods
One really nice feature of extension methods is that they can be called on null objects, see this:
myclass x = null;
x.extension_method(); // this will work
x.method(); // this won't
It is a pity, that for example most methods of string are not extension methods, after all
x.ToLower();
should return null if x is null. I mean, it would be useful.
When I need such null-transparency I prefer writing extension methods.
Suppose you have some method that could be made static, inside a non-static class.
For example:
private double power(double a, double b)
{
return (Math.Pow(a, b));
}
Do you see any benefit from changing the method signature into static? In the example above:
private static double power(double a, double b)
{
return (Math.Pow(a, b));
}
Even if there is some performance or memory gain, wouldn't the compiler do it as a simple optimization in compile time?
Edit: What I am looking for are the benefits by declaring the method as static. I know that this is the common practice. I would like to understand the logic behind it.
And of course, this method is just an example to clarify my intention.
As defined, power is stateless and has no side effects on any enclosing class so it should be declared static.
This article from MSDN goes into some of the performance differences of non-static versus static. The call is about four times faster than instantiating and calling, but it really only matters in a tight loop that is a performance bottleneck.
There should be a slight performance improvement if you declare the method static, because the compiler will emit a call IL instruction instead of callvirt.
But like the others said, it should be static anyway, since it is not related to a specific instance
Note that it is highly unlikely the compiler is even allowed to make that change on your behalf since it changes the signature of the method. As a result, some carefully crafted reflection (if you were using any) could stop working, and the compiler really cannot tell if this is the case.
Do you see any benefit from changing the method signature into static?
Three benefits:
Making stateless methods static helps document and clarify their purpose. Otherwise, one is inclined to worry just what mysterious state does the method depend upon?
The static method can be called from other static code, so is potentially more useful.
Static method calls have a smidgin less runtime overhead than instance ones. The compiler can't do that transform automatically -- one reason why is because it would affect use of null. Calling the method on a null reference is required to fail with a NullReferenceException, even if there is no instance state used within the method.
To me an easy question to decide is "Should I have to instantiate this object just to call this function". In the case of your function, I would say the answer is no, so it should be static. This method does not seem to be related to your object so again, I vote static.
Members that do not access instance data or call instance methods can be marked as static (Shared in Visual Basic). After you mark the methods as static, the compiler will emit nonvirtual call sites to these members. Emitting nonvirtual call sites will prevent a check at runtime for each call that makes sure that the current object pointer is non-null. This can achieve a measurable performance gain for performance-sensitive code. In some cases, the failure to access the current object instance represents a correctness issue.
The compiler will likely consider inlining this when it "JITs" the code as it's so short and if it does so then will likely be able to optimise out any reference to the unused this parameter. But you can't rely on any of that.
You still have to make an object to call it on unless you make it static which has a much bigger overhead anyway if you don't need one for other reasons.
this method should be static because it is not related to your class or member of classes. it just works with the inputs to this function.
maybe you may need to call it without creating that class. so if it is static it is ok but if it is not, you cant call it without any instance of that class.
Advantages of a static method:
There's no need to create an object first. The method is available immediately.
It's a good when you have generic functionality that does not depend on the state of a particular object. For example, look at the Arrays class or the Collections class from java.util.
Static methods can be good for factories. Pass your requirements as parameters, get a brand new object back. Not a constructor in sight.
Disadvantages of a static method:
You don't have an object instance, so you only have access to static members and your own local variables. If you want an instance, you probably have to create it yourself.
You can create subclasses, but a static method can't be abstract, so it's harder to decouple your implementation from a caller.
(ps: i dont think compiler will optimize if it is going to be static or not.. but not sure)
I believe the compiler will not optimise this into a static method. There is a performance gain since the pointer will not have to be checked to see if it is null at runtime. Have a look at the FXCop rule for reference.
i hope we need to define the difference between static and non-static method. Here i am posting few easy lines of code to visualize the conceptual difference.
public class StaticVsNonStatic
{
public string NonStaticMethod() //non-static
{
return "I am the Non-Static Method";
}
static public string StaticMethod() //static
{
return "I am Static Method";
}
}
Now lets create an aspx page try to access these 2 methods defined in the class.
public partial class StaticVsNonStatic_StaticVsNonWorkplace : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
StaticVsNonStatic objStaticVsNonStatic = new StaticVsNonStatic();
lblDisplayNS.Text = objStaticVsNonStatic.NonStaticMethod(); //Non Static
lblDisplayS.Text = StaticVsNonStatic.StaticMethod(); //Static and called without object
}
}
Thanks and please post you comments.
Best Regards, Pritom Nandy [Bangladesh]
I wrote an extension method for String to get a char argument, string.Remove(char). But when I used this, it instead called the default string.Remove(int) method.
Shouldn't the presence of an actual method have higher priority than an implicit conversion?
Instance methods have priority over extension methods. Your observation is proof of the same.
When resolving which method to call, it will always pick a matching instance method over an extension method... which is intuitive in a way.
Paraphrased from C# in depth,
When the compiler sees that you're
trying to call a method which looks
like an instance method but is unable
to find one, it then looks for
extension methods (that are visible
based on your using directives). In
case of multiple candidates as the
target extension method, the one with
"better conversion" similar to
overloading (e.g. if IChild and IBase
both have a similar extension method
defined.. IChild.ExtensionMethod is
chosen)
Also a hidden code-breaker could be lets say TypeA didn't have SecretMethod as an instance method in Libv1.0. So you write an extension method SecretMethod. If the author introduces an instance method of the same name and signature in v2.0 (sans the this param), and you recompile your source with the latest-n-greatest Libv2.0, all existing calls to the extension method would silently now be routed to the new instance method.
This behavior is correct. The reason is that introducing an extension method should not change the way existing code executes. Code should behave exactly the same with or without this "superfluous" extension method. It may seem counter-intuitive in certain cases (like yours), but happens for a reason.