m.invoke() vs. m()

[Reinier Zwitserloot]

It's going to be bolted on. Simple as that.

There are going to be concessions. Lots of them.

There's limited budget for  complexity.

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.

Also, just to throw a wrench in the works, from a style perspective, I think
'.invoke' is much cleaner. Which shows exactly why style sensitivities have
no place in this discussion. We all have our own idea. We most certainly
don't represent your average java programmer, so even a tally of votes for
style choices is unlikely to lead to the right answer.

--Reinier Zwitserloot



On Mon, Dec 7, 2009 at 6:33 AM, Eric Jordan <ewjordan at gmail.com> wrote:

> On Sat, 5 Dec 2009 20:45:02 +0100 Reinier Zwitserloot
> <reinier at zwitserloot.com> wrote:
> > Show me either how we can leave off 'invoke' without a sizable set of
> > changes to the JLS, or how the burden of typing ".invoke" is sufficiently
> > heavy for it to be worth abolishing even with the serious repercussions I
> > showed in my previous post. I'm not at all interested in your style
> > sensitivities.
>
> Style sensitivities and removal of boilerplate are two of the primary
> reasons that closures are being added, so they both need to be an
> important part of the discussion.  Java doesn't need the dubious
> distinction of having the most verbose closure invocation syntax of
> any popular language, even if it is just by a few characters.  A
> pointlessly verbose call syntax (from a user standpoint, I mean - no
> programmer in his right mind would ever name a closure the same thing
> as a method, as I'm sure everyone would agree, so cluttering the
> syntax to allow for that possibility *is* pointless) will make it
> painfully clear that this was "bolted on", and that will not be well
> received.  I suspect it would become one of the primary examples
> people point at to show how Java "got closures wrong."
>
> As far as I can tell, you already agree that the only problem with
> putting closures into both variable and method namespaces is that it
> complicates the spec/implementation, not that there's any useful
> reason to prefer the ".invoke" syntax.  As long as the changes are
> feasible, and I seem to recall Neal indicating that they are, then I
> don't really see what the problem is: millions of people will be using
> the new syntax, surely a bit of work to do it "right" is worth
> considering, no?
>
> Is it your claim that the changes would not, in fact, be feasible to
> implement?  In that case I'd be more inclined to let this one go
> (you're right, it's not too much extra work to type ".invoke", even if
> it is just line noise), but I'm getting the sense that you don't think
> it's important enough to waste any energy on at all, which I strongly
> disagree with.  This is a very visible and core component of closures,
> and people will notice and criticize even the tiniest bit of bloat in
> the syntax.
>
> - Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091207/749b7052/attachment.html