The Same Code, Part 2 (or "why lambda pwns")
In my last entry I had several blocks of code doing the same thing with the same basic API (all derived from jDBI, or equivalents in similar languages (Scheme, Ruby)). It was for two reasons: the first is because I had been IM'ing people with "huh, look at this" with rafb pastes. That got annoying, the second is because the look of the code was interesting.
The look of the code is just watching the form of the source. The imperative code is very imperative looking; the (objectified) scheme-ish code is a slant; the functional style code (Java with callbacks, Ruby) with statement (as compared to expression) oriented languages was all sideways-V shaped (the scheme would be too except that the formatting tradition is different).
Darren Oakey added some C#:
using (Transaction.Called("Read stuff"))
using (QueryDataSource data = dbi.open())
foreach (DaraRow row in data.Query(CHANGED_DESCRIPTIIONS ))
Console.Writeline( row.Name );
Which is quite nice, but misses the exception handling, which is important. (note: I didn't make the imperative Java as complicated and nasty looking as possible, I tried to capture the same behavior (see the ConnectionHandle#executeInternal implemenation for full exception boilerplate) as the more functional style.)
JDBC exception handling is bloody boilerplate. I suspect 50% of IDEA users have a live template for it, and the rest are slapping their foreheads right now. Libraries exist to get rid of boilerplate, but you cannot exactly say something like
beginExceptionHandlingBlock();
doJDBCStuff();
endExceptionHandlingBlock();
and have it magically work. So sad. The point is that you need to pass the innermost part of the exception handling boilerplate to the library function -- Java makes this possible, though verbose. Better C#, imho, would have been along the lines of:
dbi.Open(delegate(Handle handle) {
handle.WithTransaction("Finding Changed Descriptions", delegate(Handle handle) {
handle.Query(CHANGED_DESCRIPTIONS, delegate(Handle handle, Map row) {
Console.Println(row.Get("name"));
})
})
});
That is pretty slick, and is why I (very much) regret that Java 1.5^H^H^H 5.0 copied the wrong things from C#.
The point is that a first class function, or in the Java case, an interface with one method (with varargs and interfaces in the language spec already, how hard would it have been to add lambda, er, I mean, delegates?), can absolutely be passed into the library, and that can be all wrapped and bundled as necesary to ensure 1) resources are closed properly, all the time, without extra boilerplate, 2) exceptions are handled properly, all the time, without extra boilerplate.