m.invoke() vs. m()
Stefan Schulz
schulz at the-loom.de
Mon Dec 7 02:13:55 PST 2009
Eric Jordan wrote:
> > Getting rid of ".invoke" is not a good place to spend it. The price is
> > far too high, and the gain is far too meager.
>
> [..]
> Re: the gain, it's really a matter of speculation. I tend to think that
> people will be annoyed, and wonder why they can't just write m() given
> that it's obvious what they are trying to do almost 100% of the time.
To me, integrating closures into Java not only is to please API
designers and concurrency specialists, but to make them a technology
intuitively and easy to use for the average developer. So the gain of
getting not only the technology right, but also the syntax and use-site
of such a feature makes the decision on whether to have it one or the
other way quite important. That is, by means of usability, the gain
could be seen as quite high (and not meager), if the way of how to
invoke a closure feels natural to any developer.
If we look back on how extensive and controverse discussions on a syntax
for defining closures in Java have been, it seems obvious that syntax is
a very important issue especially for the feature's acceptance. As in
most applications, user interface design and usability design is one of
the main parts of development. Here, the developer is the user, hence
the design of a feature (it's syntax) should not be understimated.
> Mark Reinhold even mentioned on
> his blog that this was one of the things that specifically bothered him
> about FCM:
>
> (http://blogs.sun.com/mr/entry/closures_qa#comment-1259782867000):
> "FCM contains many good ideas but I'm troubled by, among other things,
> the subtle distinction between method literals and method references,
> the necessity of writing "m.invoke()" rather than just "m()" to invoke a
> method, and the complexity of named inner methods."
The style of invocation was never an FCM only topic, but was derived
from BGGA. Stephen and I simply did not consider tweaking around with
name spaces. As Neal mentioned recently on this list, it might be
feasible to put function-typed variables in both, method and variable
name spaces. Hence, I would surely prefer to use "m()", too, because it
feels natural to me from all the other C-like programming languages I
know of supporting closures.
Stefan
More information about the closures-dev
mailing list