Framework Design Guidelines: Extension Methods

re: Framework Design Guidelines: Extension Methods

Rune Juhl-Petersen — Tue, 13 Jan 2009 13:10:31 GMT

Extension methods are just great, making code more readable and understandable.

I'm missing static extension methods (define a static method on a class or interface). Are there any plans to include that at some point?

re: Framework Design Guidelines: Extension Methods

Andrei Rinea — Tue, 13 Jan 2009 17:53:53 GMT

Along with static extension methods a nice addition would be extension properties.. In fact they're still methods behind the scene, right?

re: Framework Design Guidelines: Extension Methods

David Nelson — Tue, 13 Jan 2009 20:02:10 GMT

Hopefully, the actual entry in the book spells out the disadvantages of extension methods more strongly:

- They are not discoverable. You can't just look at intellisense or the class documentation to discover its capabilities. You have to have foreknowledge that the functionality you want exists and what namespace to find it in.

- The are fragile. Extension methods introduce a new version of the Fragile Base Class problem, where an instance method introduced in a later version of a class will silently and transparently replace the extension method. For some reason, no steps were taken to mitigate this problem in the design of extension methods.

Extension methods and Interfaces.

@ Head — Thu, 15 Jan 2009 07:59:06 GMT

A comment by Joe Duffy on the Framework Guidelines for Extension says : Extension methods can also be

Extension methods and Interfaces.

VB Feeds — Thu, 15 Jan 2009 09:00:42 GMT

A comment by Joe Duffy on the Framework Guidelines for Extension says : Extension methods can also be

re: Framework Design Guidelines: Extension Methods

Dave — Fri, 16 Jan 2009 14:01:46 GMT

Personally I find that extension methods clobber the code. People who are unfamiliar with the extensions used might be confused that SqlCommand suddenly had an SetErrorCallback.

cmd.SetErrorCallback( (e) => Console.WriteLine(e.Message));

Might seem out of place in stead of

SqlCommandUtil.SetErrorCallback(cmd, (e) => Console.WriteLine(e.Message))

in your code what would be used by the compiler eventually.

I haven't found one usefull usage of extention methods.

Extension Method Guidelines

Patrick Steele's .NET Blog — Tue, 20 Jan 2009 16:23:52 GMT

I'm spending some time this morning getting caught up on RSS reading.  A great post from last week

Extension Method Guidelines

Patrick Steele — Tue, 20 Jan 2009 19:47:13 GMT

I'm spending some time this morning getting caught up on RSS reading.  A great post from last

re: Framework Design Guidelines: Extension Methods

Christopher Harris — Tue, 20 Jan 2009 22:12:04 GMT

I agree with Andrei! Extension properties might be awesome, the other day I was really wishing I could make a TimeSpan.OneDay extension property.

Also, I actually favor keeping my extensions somewhat hidden. The extensions I use on one project aren't necessarily always applicable in another.

re: Framework Design Guidelines: Extension Methods

Kevin Westhead — Thu, 22 Jan 2009 06:09:29 GMT

As David points out, there are disadvantages to extension methods but the full text does cover them. However I'm not convinced about the concerns with discoverability. Extension methods are typically used in scenarios where static methods on helper classes would have been used before. With extension methods you need to know the namespace but with static helpers you need to know the class name. This might not be obvious if you're dealing with more derived types. Both approaches have problems but I've frequently found that extension methods naturally end up in a commonly imported namespace, which means IntelliSense is usually available for all compatible types. Nonetheless, as others have already said and as the full FDG text states, extension methods shouldn't be used frivolously.