Regarding debugging, it isn’t you are I that I am worried about. Not every developer on my team has the same level of experience, however, hence some of my concern.

Regarding perf, I do agree with you that there are far bigger fish to fry but one problem that can come up with approaches like these (and the disposable approach presents similar possible issues) is that if they are going to hurt your perf they are going to do it in a way that is often spread quite widely across your app, but in tiny increments in each location. It is as if the entire app drags a bit, and since it drags the whole app equally (assuming you’ve used these mechanisms in enough places to have them being hit across a large percentage of application usage) it can be hard to diagnose and correct the issue because it won’t reveal a clear hotspot in a profile. Harder, at least, than killing the worst hotspot and moving onto the next one. Now, that’s not to suggest that this is even remotely insurmountable, of course. Rather just to say that one needs to keep a slightly different kind of lookout for the effects of mechanisms like these because they can drag the app down a bit differently than most normal perf issues do. I mention it only because I’ve seen people with reasonable amounts of experience and a profiler in hand still miss this kind of issue, that’s all.

In any case, thanks for the post and the kind exchange of commentary!

I’ve not had any trouble with debugging lambdas, and Fluent NHibernate is pretty heavy in them. Maybe I’ve got it yet to come…

Regarding performance, I never worry about it when it comes to syntax. The implications of using lambdas on performance will be so negligible compared to a badly written DB query, or IO operations, it’s not even worth thinking about. Unless somebody can prove to me there is a significant performance loss (and I’m talking seconds, not microseconds), then I’m not worried.

1. (and this is the biggie, as far as I’m concerned) stack trace obfuscation. There’s nothing like seeing a tonne of anonymous classes and their methods popping up all over your stack traces to send someone running for the hills when trying to diagnose an issue in lambda-heavy code.

2. Perf overhead. When the pedal needs to hit the metal, I suspect that a compiler-inserted try/finally with a dispose call in the finally is going to destroy the anonymous class instantiation / delegate invocation perf-wise. Admittedly, I have no numbers to back this up at this point as I am fundamentally more concerned about issue #1 at the moment, but the potential perf issue is there nagging me in the back of my mind. Has anyone compared perf, I wonder?

Your solution is actually the exact solution ruby uses as one of its main idioms — except in ruby, lambda syntax is even more readable because of adjacent lambda parameters and the do..end syntax:

File.OpenRead(“myFile.txt”) do |file|
# do something with the file
end

And, of course, there’s Boo to the rescue with its own flavor of the same thing:

File.OpenRead(“myFile.txt”) do(file):
// do something with the file
end

Which, combined with meta methods and parentheses-less invocations, means you can make your scopes work their magic at compile time rather than at runtime, which really allows freedom in declaring custom scopes.

With the proliferation of lambdas in frameworks, I’d hope that they’ll move into the collective developer consciousness before too long.

Ignoring the regular developer tax for a moment, I still believe the using statement itself is redundant in most of the non-disposable usages of it. We’ve come to ignore it in most cases. using (mocks.Record()) doesn’t really make sense when you read it, but mocks.Record(() =>) does.

Your statement ‘No more unclear “using”’ to me is false. Lambda’s are much harder to read/understand for the average developer.