Extension Methods in C# [modified]
-
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.
Jesse Jacob wrote:
but they DID say it as clearly as everyone else here did.
Well, I don't think so. If it had been stated as clearly, I wouldn't have felt confused.
Jesse Jacob wrote:
It looks like you jumped to conclusions looking for the most fishy-sounding quotes, and started attacking a strawman.
Well, yes. That's quite true. But the reason I made the post on CP was to get clarification. OK, I did come off sounding a bit holier-than-thou, so you have a point.
Jesse Jacob wrote:
if you don't trust the implementation of the .NET framework
So far, we've seen language features in C# that aren't really anything new. Even the lambda expression stuff isn't new in the big picture of programming languages. But extension methods is, I feel, unique to .NET. The quote even says that. And frankly, I don't think it's well thought out, for reasons I previously stated. For example, what I'm struggling with is some good use cases for extension methods, so that from use cases, I can extract "best practices". Put yourself in the position of a teacher, who's introducing extension methods to students. So much of what is taught nowadays seems to be "ooh, isn't this a cool technology that you can do x, y, and z with". But that's not what interests me. What I, as a teacher would discuss, is the fundamental problems that the language feature solves, examples (use cases), and best practices so that you know when to apply the language feature and when to consider other options.
Jesse Jacob wrote:
Get used to it.
No. I'm sorry, but I will question things until I understand them and know how to work with them correctly. Marc
-
Jesse Jacob wrote:
but they DID say it as clearly as everyone else here did.
Well, I don't think so. If it had been stated as clearly, I wouldn't have felt confused.
Jesse Jacob wrote:
It looks like you jumped to conclusions looking for the most fishy-sounding quotes, and started attacking a strawman.
Well, yes. That's quite true. But the reason I made the post on CP was to get clarification. OK, I did come off sounding a bit holier-than-thou, so you have a point.
Jesse Jacob wrote:
if you don't trust the implementation of the .NET framework
So far, we've seen language features in C# that aren't really anything new. Even the lambda expression stuff isn't new in the big picture of programming languages. But extension methods is, I feel, unique to .NET. The quote even says that. And frankly, I don't think it's well thought out, for reasons I previously stated. For example, what I'm struggling with is some good use cases for extension methods, so that from use cases, I can extract "best practices". Put yourself in the position of a teacher, who's introducing extension methods to students. So much of what is taught nowadays seems to be "ooh, isn't this a cool technology that you can do x, y, and z with". But that's not what interests me. What I, as a teacher would discuss, is the fundamental problems that the language feature solves, examples (use cases), and best practices so that you know when to apply the language feature and when to consider other options.
Jesse Jacob wrote:
Get used to it.
No. I'm sorry, but I will question things until I understand them and know how to work with them correctly. Marc
I've had this argument with lots of different .NET and Java programmers: either you're excited about the new stuff or you dread it, seems to me. I'm not in the dread camp. For example, .NET 2.0 gave me a bunch of new controls and framework extensions that made the apps I was already building much faster, and helped me design my newer apps a lot better. .NET 2.0 added WAY more language-changing features to the CLR than 3.5 has. Anonymous methods, nullable types, and generics provide most of the foundation for LINQ, and have had a significant impact on the way I code, at least. If you take the time to learn them (they are optional, except for the newer framework parts that only use generics), they can make hard things easy, and easy things cleaner, resulting in more comprehensible code.
Marc Clifton wrote:
But extension methods is, I feel, unique to .NET. The quote even says that.
They aren't. See Ruby mixins and the decorator pattern. The implication made by the article author is only that extension methods aren't a standard OO concept.
Marc Clifton wrote:
And frankly, I don't think it's well thought out, for reasons I previously stated.
Now we're just beating a dead horse. You're entitled to your opinion on whether or not EM is well thought out, but you haven't presented any evidence. All we have to go on is the weird "there goes Microsoft again!" tone of your initial post, followed by at least 20 posts explaining in detail that you're wrong.
Marc Clifton wrote:
Put yourself in the position of a teacher, who's introducing extension methods to students. So much of what is taught nowadays seems to be "ooh, isn't this a cool technology that you can do x, y, and z with".
Agreed: if you try teaching every bit of syntactic sugar before your students understand control structures, data structures, and classes, you'll probably confuse the heck out of everybody. After they understand the basics, what's the harm? A great example of how the simple addition of partial classes can help n00bs in .NET 2.0 is the winforms designer: the designer now isolates all of its changes in the
.Designer.cs file. In 1.0 and 1.1, a complicated form quickly became enormous and unwieldy, and accidental modifications could blow up the designer.
Marc Clifton wrote:
No. I'm sorry, but I will question
-
I've had this argument with lots of different .NET and Java programmers: either you're excited about the new stuff or you dread it, seems to me. I'm not in the dread camp. For example, .NET 2.0 gave me a bunch of new controls and framework extensions that made the apps I was already building much faster, and helped me design my newer apps a lot better. .NET 2.0 added WAY more language-changing features to the CLR than 3.5 has. Anonymous methods, nullable types, and generics provide most of the foundation for LINQ, and have had a significant impact on the way I code, at least. If you take the time to learn them (they are optional, except for the newer framework parts that only use generics), they can make hard things easy, and easy things cleaner, resulting in more comprehensible code.
Marc Clifton wrote:
But extension methods is, I feel, unique to .NET. The quote even says that.
They aren't. See Ruby mixins and the decorator pattern. The implication made by the article author is only that extension methods aren't a standard OO concept.
Marc Clifton wrote:
And frankly, I don't think it's well thought out, for reasons I previously stated.
Now we're just beating a dead horse. You're entitled to your opinion on whether or not EM is well thought out, but you haven't presented any evidence. All we have to go on is the weird "there goes Microsoft again!" tone of your initial post, followed by at least 20 posts explaining in detail that you're wrong.
Marc Clifton wrote:
Put yourself in the position of a teacher, who's introducing extension methods to students. So much of what is taught nowadays seems to be "ooh, isn't this a cool technology that you can do x, y, and z with".
Agreed: if you try teaching every bit of syntactic sugar before your students understand control structures, data structures, and classes, you'll probably confuse the heck out of everybody. After they understand the basics, what's the harm? A great example of how the simple addition of partial classes can help n00bs in .NET 2.0 is the winforms designer: the designer now isolates all of its changes in the
.Designer.cs file. In 1.0 and 1.1, a complicated form quickly became enormous and unwieldy, and accidental modifications could blow up the designer.
Marc Clifton wrote:
No. I'm sorry, but I will question
Jesse Jacob wrote:
but you haven't presented any evidence
Granted. However I think I'm entitled to "intuition" based on 25 years of programming experience. But your point is well taken. When VS2008 is RTM'd, I'll be spending more time with extension methods and I'll investigate it from the perspective of "best practices", and then I will have evidence.
Jesse Jacob wrote:
After they understand the basics, what's the harm?
Oooh. I'm really surprised you ask that. Let's take your partial classes example. The harm is that partial classes now "hides" what should really be a clean separation of concerns--the UI from the business logic. With partial classes, you can forget that you have really not separated these concerns into robust, loosely coupled, easily testable components.
Jesse Jacob wrote:
To reiterate my stance, attacking *optional* syntax changes that have the potential to make cleaner code is just silly, in my opinion.
Well, I still think I was questioning. However, in my experience, optional things are the very things that are abused and misused the most, and demand the some best practices guidance from the get-go.
Jesse Jacob wrote:
I will, however, thank you
hehe. You're welcome.
Jesse Jacob wrote:
and I honestly can't wait to tear into WPF and XLinq on my next project--we've already identified a lot of problems they can help solve.
Since I'm not in that same position, I am definitely interested in what problems they can help solve, if that's something you'd care to continue investing time in discussing with me. :) For my part, what I've benefited tremendously from is the declarative concepts that WPF and WF are founded on. I have clients that instantly "get it" when they realize that the entire UI and UI workflow is defined declaratively on the server, not to mention the databinding as well. As to Linq (x/d/etc), I really need to work with it to see its benefits. It may be that I'm simply working in a different problem domain than others, because I see very little application of Linq for the problems I'm working on. However, I would like to thank you for your discussion so far! Marc
-
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 MicrosI think the opportunity for over-use or abuse is present, but I can also see the benefits. As an example, we use the ExtendedProperties of a DataTable and DataColumn quite a bit in our own custom DataSet. Currently we have the code for retrieving these properties values in our DataSet class (as a static helper), but by using extension methods we would be able to place the code against the DataTable and DataColumn classes, which would be a more intuitive place to look. Another example would be the String class, such as adding a ToProperCase() method, much nicer and easier for developer (via intellisense) than a static helper class.