Delete comment from: Neal Gafter's blog
Doug Lea had some interesting comments about the fork-join framework and its supporting interface types, in relation to closures.
It's worthwhile comparing the number of classes and interfaces in the closures and non-closures version of fork-join. There's something like a 50% reduction in the closures version... that's a big signal-noise ratio improvement.
Fork-join isn't the only library which would benefit in that manner. I've seen plenty of decent libraries end up ignored or under-utilized due to being swamped by myriad variations of general interface types like Combiner, Function, Mapper, Generator etc. I've ignored or under-utilized them myself :-)
After all, what does the javadoc for the Combiner interface tell you that the corresponding function type doesn't say in place, as part of the method signature, rather than somewhere else on another page in the javadoc? What can it tell you? It can't tell you much about what it does, because the user of the API is providing that all important detail when they create an implementation. It could tell you how it will be used by the combine() method, but surely that information belongs as part of combine()'s documentation.
True, with grep or an IDE you could search for all uses of this interface since it has a name, but how often does anyone do that with such a general interface? I certainly don't recall ever doing it with something like Runnable. Far more likely I'd want to search for uses of the combine() method itself.
There's also an interesting sentence in the CICE proposal:
"At the same time as this facility is added to the language, it would make sense to add a few more single method interface types, such as Predicate, Function, and Builder"
Presumably not to support any "exotic" styles of programming though... ;-)
Dec 13, 2007, 8:17:00 PM
Posted to What flavor of closures?