closures after all?
lk at teamten.com
Fri Nov 20 16:35:12 PST 2009
> 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.
More information about the coin-dev