This is a bit of a follow up to
and was provoked by running NDepend over -- naturally -- my current .net project as a first test drive (and being a work in progress, the debug build). Which then it highlit a number of quite simple methods involving function chaining as being candidates for refactoring (as well as the tut-tutting at the code generated for the
Either< 'a,'b > type).
Let's look that series of short-circuitable tests, mentioned in the first post, something that would look like
Let's have a type that expresses the intent more directly than a general purpose boolean, and a couple of helpful combinators...
Then we can write the chained tests as
Reflector shows us that the IL that comes out of the process in a debug build corresponds to code that looks like
Test function being used is a member function of the class, you get temporaries like
defined and being passed into the local lambdas; and there is no re-use of these temporaries.
Fortunately, the code generated in a release build avoids creating one-shot variables for these intermediate input values (and optimizes away the call to
ignore) -- but it still has a separate tuple value for each test, rather than re-using a single name. Chain enough calls together and the number of hidden variables will start to trigger metrics-based alarms.
It looks like F# code is going to be rather heavy going for tools to work with.
This is unchanged with the Feb 2010 CTP (184.108.40.206).