closures after all?
Lawrence Kesteloot
lk at teamten.com
Fri Nov 20 16:35:12 PST 2009
Neal,
> 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?
Describing an integer or float is usually straightforward. It can be
done in a sentence or two. Describing a function is more complicated.
What would the javadoc even look like?
* @param handler function called when the mouse is clicked.
* @param mouseEvent information about the click.
* @throws NullPointerException if mouseEvent is null.
* @return whether the event was handled.
And that's for a simple 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.
Mouse events are a common example of closure usage. I have no doubt
the unwise choice would have been made.
> 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.
That's precisely what I'm advocating. I want the language to protect
as much as possible against unwise choices, to the point of denying
features that are sometimes used wisely. Java has done this pretty
well so far, but it's slipping, and once it becomes an expert-only
language there will be nowhere for the rest of us to go.
Lawrence
More information about the coin-dev
mailing list