closures after all?

[Neal Gafter]

On Fri, Nov 20, 2009 at 3:30 PM, Lawrence Kesteloot <lk at teamten.com> wrote:

> 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'm not objecting to allowing it, I'm objecting to requiring it.  You allow
it simply by not saying anything in the spec at all.


>  >> 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.


Right.  Like for a parameter of primitive type, that would correspond to the
contract on the primitive value contained in the parameter, not the
primitive parameter itself.  Where do you put that documentation?


> 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 addMouseListener.  But if the type is widely used, as you suggest is the
case here, then the API designer would have made an unwise choice.  I do not
think we can protect against unwise API designers by denying language
features that are more wisely used in some circumstances than others.