Extension Methods in C# [modified]
-
Judah Himango wrote:
compiles down to essentially something like this:
So, the implication is that Linq is syntactical frosting on top of extension methods, which is syntactical sugar? [edit] Furthermore, the implication is that Linq could be done without extension methods, in contradiction to what the author in the first article I link to states [/edit] Marc
Marc Clifton wrote:
the implication is that Linq could be done without extension methods, in contradiction to what the author in the first article I link to states
LINQ is just a bunch of classes. There is a whole bunch of other syntactic sugar to make it look more SQL-like. You can use the whole lot without any of the new sugar. Microsoft's Daniel Moth has a good blog post on Decomposing LINQ[^]
Upcoming FREE developer events: * Glasgow: SQL Server Managed Objects AND Reporting Services ... My website
-
I was reading this on the MSDN site: A new feature made available in Visual Basic 2008, however, lets you extend any existing type's functionality, even when a type is not inheritable. And these extension methods play a crucial role in the implementation of LINQ. Many types that already exist can't be easily updated without breaking existing code. An example of this is the interface IEnumerable(Of T). In order to support LINQ, new methods had to be added to this interface, but changing the interface by adding new methods would break compatibility with existing consumers. Adding a new interface was a possibility, but creating a new interface to supplement the existing IEnumerable(Of T) interface would have appeared to be an odd design. What was needed was a way to extend existing types with new functionality without changing the existing contract. Is this true? That extension methods were added for the purpose of supporting Linq? The article[^] also makes some wierd points: Extension methods allow you to add functionality to a type that you don't want to modify, thus avoiding the risk of breaking code in existing applications. You can extend standard interfaces with additional methods without physically altering the existing class libraries. You can extend .NET types and older COM/ActiveX® control types for new code without risk of breaking old applications that use these types. Prior to extension methods, in order to add functionality to classes and interfaces, you had a few options: * You could add the functionality to the source code, but this requires access to source code that may not be available. * You could use inheritance to inherit the functionality contained within one type into a new derived type, but not all types were inheritable. * You could re-implement the functionality from scratch. What I find odd about this is the assumption that one would want to add functionality to a class or interface. I mean, what's wrong with just calling, say, a static helper method? The example in the article, the
AlternateCasemethod, seems ridiculous to implement as an extension method. Is this simply because the example is contrived? As the author points out: This is not a standard object-oriented concept; it is a specific MicrosCalled OO. It seems Microsoft goes far out of its way to make it impossible to use with its various technology offerings. Many of the API classes are not only sealed, but are missing crucial methods (think try parse in 1.1) Even worse, some of the ones that are not sealed do not provide many of the virtual methods needed. I can understand it, however, MS is about creating technicians and not programmers and OO is a difficult concept to teach a technician.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway -
Judah Himango wrote:
compiles down to essentially something like this:
So, the implication is that Linq is syntactical frosting on top of extension methods, which is syntactical sugar? [edit] Furthermore, the implication is that Linq could be done without extension methods, in contradiction to what the author in the first article I link to states [/edit] Marc
Yes LINQ syntax is entirely frosting that just compiles down to regular old method calls. And yes, extension methods are also syntax frosting that compile down to regular old method calls. LINQ is also a bunch of libraries to make working with data easier. (These libraries heavily use extension methods. For example, the LINQ
wherekeyword compiles down to a call to an LINQ library extension method, LinqExtensions.Where(...), that extendsIEnumerable<T>. This *could* have been done without extension methods, however, so the article is wrong in that sense.) For what it's worth, you can bypass all LINQ syntax candy and all extension methods, and still use the LINQ libraries. The result would look something like this:// Using LINQ without any of LINQ's syntax candy. This is what the compiler will generate.
var evenNumbers = LinqExtensions.Where(numbers, i => i % 2 == 0);The libraries that make up LINQ induce you into writing more declarative code, which I think we both agree is a good thing. And since we're declaring what we want, rather than telling the compiler how to get it, other libraries can take advantage of this fact and do interesting things. A concrete example is the ParallelFX library coming down the pipes; with it, you could write:
var evenNumbers = (from i in numbers where i % 2 == 0 select i).AsParallel();
And immediately, your query runs on multiple processor cores, getting faster as more cores are added.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Forgive Me Father, For I Have Sinned: A Catholic Confession Regarding Sabbath The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
Extension method are normal method. Only the compiler can use them (not the runtime), as per the documentation: "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." elsewhere in the documentation: "You can use extension methods to extend a class or interface, but not to override them. An extension method with the same name and signature as an interface or class method will never be called. At compile time, extension methods always have lower priority than instance methods defined in the type itself." As you can see, they are only syntaxic sugar. I like them, of course I still need to define in my static helper class, but I like to see the new utility method appear on the class I use! :-D (plus intellisense has a special symbol for them, in the combobox, so you know they are extension) Plus I confidently know I didn't break anything, they are just syntaxic sugar.
Super Lloyd wrote:
Only the compiler can use them (not the runtime)
Does this mean there is no reflective ability to obtain a set of extension methods for a given class at runtime... even to do so manually? That is, is there a standard convention by which the static IL methods are named/attributed that would allow them to be identified at runtime and invoked programmatically?
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
-
Judah Himango wrote:
compiles down to essentially something like this:
So, the implication is that Linq is syntactical frosting on top of extension methods, which is syntactical sugar? [edit] Furthermore, the implication is that Linq could be done without extension methods, in contradiction to what the author in the first article I link to states [/edit] Marc
Marc Clifton wrote:
So, the implication is that Linq is syntactical frosting on top of extension methods, which is syntactical sugar?
Mmm... frosting... :-D
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
-
Marc, Take a look at these two blog posts...they may help explain extension methods a bit better: C# 3.0 Extension Methods Follow Up[^] Generic Enum Parsing with Extension Methods[^] Rhino Mocks + Extension Methods + MVC == Crazy Delicious[^] The reality of extension methods is that when you write them, you really are just writing a static class of helper methods. The only difference is the use of the
thiskeyword in front of the first parameter. You can access them using the extension syntax or through the helper class. In fact, if you look at the code in reflector, you will see that the compiler is actually accessinng the method through the static class just like you would normally do. The extension syntax is simply more syntatic sugar. The benefit of using extension methods starts to show by providing a more natural syntax for the helper methods. Your example ofTools.StringToUpper(s)is actually good in that the natural way to think about this is I want to make the current string object's value upper case. Given this, it's more natural to see code like this (although in this case, the name makes it a bit awkward):string s = "this is a test";
s.StringToUpper();rather than code like this
string s = "this is a test";
s = Tools.StringToUpper(s);I'm not sure I agree with the statement that one is more readable than the other; I think they are both equally readable. However, I think the extension method "flows" better and shows the intent with slightly less code at the calling site.
Scott.
—In just two days, tomorrow will be yesterday. [
I am concerned about one thing: the fact that the use of the extension method does not mention "where" the method comes from. What if you define two (independent) extension methods called StringToUpper()? How does the compiler know which one to choose, and more importantly, can it be disambiguated by saying something like: s.(Tools.StringToUpper)(); ...? Obviously it wouldn't look like that, but the question stands. Logan
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
-
I am concerned about one thing: the fact that the use of the extension method does not mention "where" the method comes from. What if you define two (independent) extension methods called StringToUpper()? How does the compiler know which one to choose, and more importantly, can it be disambiguated by saying something like: s.(Tools.StringToUpper)(); ...? Obviously it wouldn't look like that, but the question stands. Logan
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
-
I'd assume it'd work the same way as disambiguation between other namespace collisions.
-- Help Stamp Out and Abolish Redundancy The preceding is courtesy of the Department of Unnecessarily Redundant Repetition Department.
-
it doesn't compile, the compiler throw an exception saying that there is an ambiguous call or something like that, just checked in vs2008
-
string s = "this is a test"; s.StringToUpper();Nothing against extension methods, but I don't actually agree that this example is a good one. If extension methods are just a cosy way of making static helpers look like instance methods on the class in question, one thing they should surely never do is change the semantics of working with that class? Your code sample makes it look like string is not immutable. I suppose the readability is arguable, but it is certainly confusing to people unfamiliar with the class being extended and could lead to bugs being introduced elsewhere, especially on classes less well known or in third party libraries. The following, for example, wouldn’t behave as expected.string s = "this is a test"; s.StringToUpper(); s.Trim();I used this example since it was the code that Marc was specifically mentioning. Looking at it, the example probably should have been
string s = "this is a test";
s = s.StringToUpper();which would have clearly shown that it isn't changing the semantics of working with the class and making a string mutable. That should also resolve your other concern about it being used improperly since it would provide the same behavior.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
-
I am concerned about one thing: the fact that the use of the extension method does not mention "where" the method comes from. What if you define two (independent) extension methods called StringToUpper()? How does the compiler know which one to choose, and more importantly, can it be disambiguated by saying something like: s.(Tools.StringToUpper)(); ...? Obviously it wouldn't look like that, but the question stands. Logan
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
It was pointed out here[^] that this would actually cause a compiler error. Effectively, the compiler wouldn't know which one to choose and so throws an error telling you that it is an ambiguous call. I don't think it's actually possible to disambiguate the call like that. There are two options:
- Choose only one namespace to include.
- Use the more traditional static helper class method calling syntax and not the extension method syntax.
I think the language rules that would be required to do this would be way too complex and the frequency such a situation might arise would be too low to warrant trying to figure out how to do this.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
-
the exception message says : "The call is ambiguous between the following methods or properties: '...()' and '...()' ... "
Interesting. Seems to me this is something of an oversight.
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
-
>>Warned by who? I think the biggest problem will be the potential for abuse by new/inexperienced programmers...but that is the case for almost any language construct. I have seen it in the explanation of the new features in MSDN articles, that extension methods should be used with caution. As for new/inexperienced programmers, my experience is that they tend to be familiarised only with the basic things that are common in java and c#, and most won't even think of using extension methods. Then they might discover them, they might use them once or twice erroneously, but that's ok and natural.
I think the more important thing to understand about extension methods are that they aren't the proverbial "big hammer". They should be used only when other approaches aren't suitable or possible. That being said, I do think there are a lot of opportunities where extension methods make perfect sense (generally for data validation type classes, or most of the other static helper classes you might have).
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
-
It was pointed out here[^] that this would actually cause a compiler error. Effectively, the compiler wouldn't know which one to choose and so throws an error telling you that it is an ambiguous call. I don't think it's actually possible to disambiguate the call like that. There are two options:
- Choose only one namespace to include.
- Use the more traditional static helper class method calling syntax and not the extension method syntax.
I think the language rules that would be required to do this would be way too complex and the frequency such a situation might arise would be too low to warrant trying to figure out how to do this.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
Since when did computer scientists ignore cases that were too "infrequent" to bother worrying about?? It seems to me the fact that this MIGHT happen even once during the course of a project is enough to warrant providing an elegant solution. I suppose the solution is, as you say, to simply resort to calling the method in the conventional static way (I presume this is still possible with extension methods), but it just doesn't feel like a "complete" solution to me. *shrug* I still think extension methods sound really handy, so I'll quite griping now. ;)
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
-
Since when did computer scientists ignore cases that were too "infrequent" to bother worrying about?? It seems to me the fact that this MIGHT happen even once during the course of a project is enough to warrant providing an elegant solution. I suppose the solution is, as you say, to simply resort to calling the method in the conventional static way (I presume this is still possible with extension methods), but it just doesn't feel like a "complete" solution to me. *shrug* I still think extension methods sound really handy, so I'll quite griping now. ;)
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
logan1337 wrote:
suppose the solution is, as you say, to simply resort to calling the method in the conventional static way (I presume this is still possible with extension methods), but it just doesn't feel like a "complete" solution to me.
Yes, calling the method in the conventional static way is still possible. In fact, that's actually what the compiler converts the code to anyway.
logan1337 wrote:
Since when did computer scientists ignore cases that were too "infrequent" to bother worrying about?? It seems to me the fact that this MIGHT happen even once during the course of a project is enough to warrant providing an elegant solution.
If this were a completely pure science I would agree with you on this point, but at some point a trade off must be made between implementing the pure (elegant) solution that accounts for 100% of all cases, including the edge cases, and the one that implements 99% as long as there is a viable workaround for the remaining edge cases.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
-
logan1337 wrote:
suppose the solution is, as you say, to simply resort to calling the method in the conventional static way (I presume this is still possible with extension methods), but it just doesn't feel like a "complete" solution to me.
Yes, calling the method in the conventional static way is still possible. In fact, that's actually what the compiler converts the code to anyway.
logan1337 wrote:
Since when did computer scientists ignore cases that were too "infrequent" to bother worrying about?? It seems to me the fact that this MIGHT happen even once during the course of a project is enough to warrant providing an elegant solution.
If this were a completely pure science I would agree with you on this point, but at some point a trade off must be made between implementing the pure (elegant) solution that accounts for 100% of all cases, including the edge cases, and the one that implements 99% as long as there is a viable workaround for the remaining edge cases.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
Scott Dorman wrote:
If this were a completely pure science I would agree with you on this point, but at some point a trade off must be made between implementing the pure (elegant) solution that accounts for 100% of all cases, including the edge cases, and the one that implements 99% as long as there is a viable workaround for the remaining edge cases.
In the sense that if the choice is between having the functionality right now with a few edge cases and having to wait for Microsoft's next language, then I completely agree with you. ;)
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
-
Super Lloyd wrote:
Only the compiler can use them (not the runtime)
Does this mean there is no reflective ability to obtain a set of extension methods for a given class at runtime... even to do so manually? That is, is there a standard convention by which the static IL methods are named/attributed that would allow them to be identified at runtime and invoked programmatically?
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
mmhh.. good question, I don't know... sorry.. :~
-
Thanks Colin (and everyone else). That helps clarify a few things. I wish the articles on MSDN would say it as clearly and well as you and the other CPians have here. Marc
I don't mean to sound like a jerk (which is just a pre-apology for sounding like a jerk ;) ), but they DID say it as clearly as everyone else here did. It looks like you jumped to conclusions looking for the most fishy-sounding quotes, and started attacking a strawman. For example: "This is not a standard object-oriented concept; it is a specific Microsoft® .NET Framework implementation feature. While this feature opens up a new set of possibilities, it's worth noting that the underlying intermediate language (IL) code generated by the compiler is really doing nothing new or specific to the .NET Framework 3.5. In actuality, it is simply making a shared method call. This means you have the capability to use this feature in Visual Basic 2008 to target earlier versions of the .NET Framework. It shouldn't introduce any additional security issues since this feature doesn't change the type being extended and doesn't actually do anything that you couldn't already do with earlier versions of the Framework." That stuff in bold is the text immediately following your "red flag". Pretty much answers all of your concerns. I don't even get the red flag comment though: if you don't trust the implementation of the .NET framework, what are you doing programming with it? Are you also mistrustful of CAS, delegates, enums, and foreach? There is no overriding global standard for implementing garbage-collected, language-neutral, object-oriented frameworks...so it's pretty much ALL ABOUT the "implementation features". Get used to it.
-
Extension method are normal method. Only the compiler can use them (not the runtime), as per the documentation: "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." elsewhere in the documentation: "You can use extension methods to extend a class or interface, but not to override them. An extension method with the same name and signature as an interface or class method will never be called. At compile time, extension methods always have lower priority than instance methods defined in the type itself." As you can see, they are only syntaxic sugar. I like them, of course I still need to define in my static helper class, but I like to see the new utility method appear on the class I use! :-D (plus intellisense has a special symbol for them, in the combobox, so you know they are extension) Plus I confidently know I didn't break anything, they are just syntaxic sugar.
Extensions are just syntactic sugar covering the actual static method implementation in the IL. Reflection will have no trouble sorting them from the native type's members.
-
Judah Himango wrote:
compiles down to essentially something like this:
So, the implication is that Linq is syntactical frosting on top of extension methods, which is syntactical sugar? [edit] Furthermore, the implication is that Linq could be done without extension methods, in contradiction to what the author in the first article I link to states [/edit] Marc
There was no implication that LINQ couldn't have been done without extensions, you came away with that on your own. He described the problem (needing to extend IEnumerable(Of T) in order to support LINQ, but not wanting the trouble of breaking or replacing it), a solution (extensions), and then three full paragraphs explaining how extensions just provide easier syntax without affecting the compiled output. That's the usual definition of syntactic sugar, my friend.