closures after all?

[Lawrence Kesteloot]

On Fri, Nov 20, 2009 at 3:02 PM, Neal Gafter <neal at gafter.com> wrote:
> A pattern-based specification can still be used with an interface like
> AutoCloseable.

But that's what you were objecting to in the current ARM proposal.

>> I have a similar objection to closures: it encourages variables and
>> parameters that are anonymous function signatures with no javadoc to
>> help me learn about the contract. (CICE is exempt from this
>> objection.)
>
> Variables don't normally have contracts.  Parameters, on the other hand,
> usually have their contracts specified in the method.

I was referring to the contract of the function the variable (or
parameter) points to, not the variable itself. For example,
JButton.addMouseListener() takes a MouseListener. I can look up
MouseListener's javadoc to figure out how I should implement it. With
closures the API designer may have been tempted to create
JButton.addMouseClickedListener() that takes an anonymously-defined
closure. Then where is the javadoc for that callback? In the javadoc
for addMouseClickedListener()? And in the javadoc of every function
that wants to pass around and manipulate mouse-clicked listeners? And
when internally that listener is assigned to a field, where is the
javadoc explaining what that function's contract is? Is that
function's contract described a dozen times, or put in only one place
and simply missing everywhere else?

Ever since generics were introduced people have asked for typedefs.
They want it to reduce typing, but I want it because I want a place to
explain what the heck is being stored in the
map-of-string-to-lists-of-strings.

Lawrence


  In the cases where
> you would use a function type, there isn't much for the javadoc to day.
> Just like primitive types, which also don't have contracts.