A few thoughts:

“you could make similar case for having all class constituents public instead of encapsulating via private, protected or internal modifiers, or perhaps using goto’s over formal control flow constructs such as for loops and if statements”

I agree the summary of the argument is not compelling in itself; it needs to be taken in the context of the rest of the post (Unwanted Extension Points, Explicit Contracts, Open/Closed Principle). In this context, I am failing to see the parallels with having all class constituents public etc.

Not a very compelling argument as you could make similar case for having all class constituents public instead of encapsulating via private, protected or internal modifiers, or perhaps using goto’s over formal control flow constructs such as for loops and if statements. While you may gain flexibility you’ll likely feel more pain with added complexity you open up. After all if you’re not going to need those extra extensibility points why go to the effort of adding them?

As the linked article says for anything more than a trivial standalone application you are really just giving yourself more rope for you (or others) to hang yourself with.

Thanks for your comments, and for the link – there are some very good points raised, particularly in regard to side effects of functions.

I’ll certainly take this into consideration.

http://blogs.msdn.com/ericlippert/archive/2009/05/18/foreach-vs-foreach.aspx

Consider his points carefully, especially the one about lambdas introducing closure semantics, before deciding that an extension method is better than a language construct in this case.

DotNetBurner – burning hot .net content…

DotNetBurner – burning hot .net content…