m.invoke() vs. m()

[Stefan Schulz]

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