Bruce Chapman's Blog: February 2008 Archive

Josh Bloch makes some interesting points in his Javapolis presentation on the closures controversy. However having listened to the audio several times and read the slides at least three times, I am having trouble extracting the salient points from all the FUD

(The presentation video of the talk is now also available)

What seems to be happening is that much of that FUD is starting to spread.

In this post I want to expose one of these items of FUD to some light and see how it really looks. Also I am hoping that having neutralised the noise, I might more easily extract some signal from Josh's talk. I think its there but I can't hear it just yet.

At 13:06 into the sound track, Josh starts comparing interfaces to function types by first refering to these javadocs for an interface and talks about it having a name, all known implementations, and documentation including semantic constraints. He then says

"with functional types all you get is 'it takes two T's and gives you a T'. There's a lot less information there."

This presumably is in reference to where the types are used. Compare this version of a method in the fork join library with this one using closures.

An Ops.Reducer is of no value except where it is used. Now with the non closures version, all we see in the javadoc for the reduce() method is the names of the type and parameter, whereas with closures we see the essential method signature, because that is the closure type, and the parameter name. The closure version tells me more because all I get without the closure is a type name and a parameter name, and if I want to know more I have to click a link to go find it. With the closure I don't ned to first follow the link.

Recently Stephen Colbourne tried to give more impetus to this FUD when he said

"A second complaint about function types is that there is no home for documentation. One of Java's key strengths is its documentation capabilities in the form of Javadoc."

To date I haven't seen anyone describe how the javadoc tool would work for closures, so let me suggest that when a method return type is a function type, or a method parameter is a function type, then the return and parameters of that closure type will be able to have nested javadoc associated with them.

I would expect you'd find the javadoc for ParallelArray.reduce () being something like

reduce
public T reduce({T,T=>T} reducer,
                T base)
Returns reduction of elements

Parameters:
reducer - the reducer. This function must be associative.
reducer returns
The result of combining the two arguments in some way
reducer parameter 1
The first argument to be combined.
reducer parameter 2
The second argument to be combined.

base - the result for an empty array
Returns:
reduction

You could do that now, but some new javadoc tags to do the nested documentation would make life simpler.

For sure those are pretty terrible javadocs, I just made them up, but this demonstrates that the function type's javadocs can be just as rich as the nominal type's.

Before you say it would get tedious writing out the same complicated javadoc at every place where you used a particular function type, let me say that the point at which it gets painful is probably the point at which you should consider using an interface rather than a function type, and the javadoc pain is your friend by helping you to see that.

And one last thing, Josh says that with an interface, you can find all the known implementations from the javadoc. Not so, you won't find the implementations that are anonymous inner classes. And those are exactly the sorts of places where you would use nominal types and closures. So that's not really an advantage of nominal types over function types in the places where you'd actually use them, it's just more FUD.

Powered by
Movable Type 3.01D

java.net RSS Feeds