Worth it just to get rid of a few braces and breaks?

It’s very usefull when building trees with Linq to Xml…

When you suggest the performance of your fluent code is an unnoticeable amount slower than a switch statement, you may be correct where the code is executed infrequently. But if the switch is inside a loop that slight difference can turn into a substantial delay. As always, use with caution.

http://lorgonblog.wordpress.com/2007/12/02/c-3-0-lambda-and-the-first-post-of-a-series-about-monadic-parser-combinators/

I think you’ll find quite a few control structures implemented in this sort of way (except as extension methods). I think Bart de Smet did something similar with If and For.

http://bartdesmet.net/blogs/bart/archive/2009/07/11/bart-s-control-library-not-what-you-think-it-is-part-0.aspx

I’d prefer to see language/framework support for the Chain-of-responsibility pattern (http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern).

For example, maybe something in the BCL like:

interface IHandler
{
bool IsHandlerFor(TContext context);
void Apply(TContext context);
}

[this is basically identical to ICommand, perhaps we could just reuse that...?]

You can then either explicitly create a class for each handler, or create a ‘reusable’ class, something like:

class Handler : IHandler {
private Func _isHandlerFor;
private Action _applier;
public Handler(Func isHandlerFor, Action applier) {
_isHandlerFor = isHandleFor; _applier = applier;
}
bool IsHandlerFor(TContext context) { return _isHandlerFor(context); }
void Apply(TContext context) { _applier(context); }
}

You could then do something like:
var handlers = new[] {
new Handler(context => context.Status == ScannedAssetState.ConfirmAssetRemove, context => ConfirmAssetRemove(…)),
new Handler(context => context.Status == ScannedAssetState.Error, context => View.ShowError(…)),
}

ApplyFirstMatchingHandler(newContainer, handlers);

This also gives you the flexibility of allowing the IoC container to automatically setup the handlers for you, if you so wish. If you did do that, then as new handlers are created (say for a new state), none of the existing code needs to change. It also means that the logic for handling that particular state is located only within the relevant handler, leading to higher cohesion.

Thoughts?

Also, there is no need to use { } brackets in cases:

switch( myObj.status ) {
case StatusEnum.Case1:
doSomething();
break;
case StatusEnum.Case2:
doSomethingElse();
break;
default:
doElse();
break;
}

I don’t think this is uglier because first it uses generics while the switch statement is limited to numbers, strings. Second there is no curly bracket soup (and that’s what i like most) so it reads better. Last switch semantics are very often useful so and easy to read and understand so it’s good to extend it to other types.

I would call this the Object-Oriented switch while the old one is the structured switch which i consider a very stinky code smell.