m.invoke() vs. m()

[Reinier Zwitserloot]

On Mon, Dec 7, 2009 at 11:46 PM, Osvaldo Doederlein <opinali at gmail.com>wrote:

> compiled/executed as method invocation. But either way it's irrelevant
> because we can just overload the "()" operator to handle both method-call
> and closure-call, there's much worse precedent for that in Java (e.g. "+").
>
>
"Java already sucks worse in regards X in area Y" is not an excuse to pile
on the hurt.


> IMHO (not being a javac developer or JLS expert) this doesn't make method
> resolution more complex


It does become more complex. Nested classes, the type of all variables all
of a sudden enters play, as unifying the namespace of fields and methods
generally is not backwards compatible, and more.


>
> This problem, as well as others I can think, seem strawmen to me.
>

How is that strawman? Do you think that people in practice never change the
types of variables, or that with closures, existing variables of SAM types
won't be rewritten to closure types? That seems quite a stretch.

[snip rant on reflection]
>

How is this in any way or form relevant to the presumed added complexity of
'.invoke'? You're comparing the need to insert a gajillion casts and catch 4
separate exception types on every reflection call with adding the letters
".invoke" to invoking closures? That also seems quite a stretch.

".invoke" does not suffer from any added complexity for users; it's
considerably simpler. Closures are represented at the system level as an
object. The payload of this closure is represented as a method (named
"invoke", as being compatible with other JVM languages is a good thing).
There's no way to abstract this away without that abstraction leaking like a
sieve. Closures will of course extend Object, meaning you can do the usual
things to them, such as reflection. Which will at the very least have to
reveal that invoke method. I haven't seen a proposal to get rid of this, and
I doubt a good one exists, so, whatever complexity you think exists in
having a closure payload exist as a method named "invoke" cannot be avoided.

Thus, we have two choices.

(A) .invoke is the only way to invoke a closure, and we get all the
complexity (insofar as it exists) of abstracting closures as a method named
"invoke" on some function type,

or

(B) we allow .invoke, *AND* we allow invoke-less straight parameter syntax.
Now we get all the complexity of A, and in addition, we get all the
complexity of B, including fields that occupy more or less namespaces
depending on their type, for example.

Clearly, choice B cannot possibly be less complex than choice A.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091208/bc8783bb/attachment.html