Greg Young [MVP]

Most valued one

Not to use extension methods at all.

This hack can be needed for API designers. But this is no point to have extension methods in regular code.

#1 rule: avoid is possible. Use existing OO techniques to extend types if possible. Extension methods == last resort.

#2 rule: just like any other code, look for reuse. See if there's an existing standard library of extension methods that solves your problem.

One interesting use of extension methods is the one I mention here: forums.microsoft.com/.../ShowPost.aspx. That is, use extension methods to extend enums for purposes such as converting to strings for the UI. However, in the WPF world I would simply use a converter or data template scoped at the application level. It would make more sense for methods unrelated to UI.

PS. Change state of what? The extension target object? Or global state? The former I don't see a problem with. The latter makes me shudder.

Pingback from  Daily Dose of Links - 20071119 « Daily Geek Bits

What kinds of side effects are you suggesting to prohibit? Would you consider changing the target a side-effect?

Put them in a namespace such that the client has to "opt-in" to the extension methods.  The namespace should only contain the extension method classes and any other classes used by the extension methods.  For example, don't put your favorite "System.String" extension methods (.ToAlternatingCase) in the "System" namespace, put it in "System.String.Extensions" or something similar.

The namespace should be explicit to both the user writing the code and the user reading the code 6 months later exactly what extensions are being brought in simply by looking at the using statements.

But the bug question is... why?  Extension methods can only hit public properties/metods.  So if an extension method changes an object via it's public properties, hows that different than something else that changes an object through it's public properties?

Hey Greg, what state? And why is it bad? Your blog post is a bit too short :)

I would agree. I believe there's benefit to mandating that class state be immutable (I'm sure I've seen this before but I can't find reference to it) so it's not much of a stretch to expect static methods (including extension methods) treat the objects they accept as parameters (or extend) as immutable. Extension methods are "special" all-around, and I think they have the propensity to make the programmer forget they're working with a static method as well as forgetting about good OO design. It is very unfortunate that you can't inject design attributes of a class into its declaration (like declaring that a class is immutable and therefore generate compile warnings on code that does modify state) and I really hope that ability is added to C# 4 (should that ever exist) and also include the ability to declare immutable static classes or immutable static state. Although, I don't think this would introduce anything to avoid writing side-effect free extension methods...

So you're saying if there's a mutable type with instance methods that perform mutations, if I add an extension method I should do things in an immutable fashion anyway? That sounds crazy to me. Callers of the APIs shouldn't be able to differentiate between instance / extension method calls - that's kind of the point of them. Yes, extension methods will be abused by some, but what tool isn't? +1 for spec# / C# convergence!

Great post.... my thoughts exactly.  I believe that extensions will be grossly over used.

Give a man a hammer, everything becomes a nail.