m.invoke() vs. m()

Ricky Clarkson ricky.clarkson at gmail.com
Sun Dec 6 02:22:40 PST 2009


> Your idea is not going to work, Ricky.

The idea was not mine.  I was commenting on your statements about Mark's idea.

> Problem #1:
> public class Test {
>     private #()void x = #() {print("1");};
>     private void x() {print "2";}
>     public static void main(String[] args) {x();}
> }

The arbitrary rule I would choose would be to cause this to give a
compile error.  That is, variables whose types are function types
would work differently in terms of namespacing.

> Problem #2:
> public class Test {
>     public static void main(String[] args) {OtherClass.x();}
> }
I think I've answered this in the answer to problem #1.

> (NB: gut instinct? Gut
> instinct has no place in discussions about language features. Please give
> actual reasons next time!)

I did not use the term 'gut instinct'.

> Code should remain generally parsable and resolvable [snip

Agreed, but I'm not sure how that affects this discussion.

> Problem #3:
> It would also lead to problems with private API.

Not with the rule I mentioned above.

> Problem #4:
> Method Resolution is already one of the most complicated aspects of java,
> and you're suggesting that we make it even more complicated.

Again, I'm not suggesting we do so.   I'm responding to your comments
about Mark's suggestion to do so, and correcting what to me are
errors.  I don't really mind whether I type f(x) or f.invoke(x).

> Right now, any parser that sees:
> ident(args);
> knows that this must mean: method invocation. It can tackle resolution by
> first trying to match 'ident' to the method namespace. Thus, if ident here
> is actually "x.y.z", then the compiler knows to look for a method named 'z'
> in a type 'x.y'. It'll have to consider both local variables and the global
> type namespace for 'x.y', which is already quite complicated, but at least
> it knows that the 'z' MUST be a method name

> Not so in your proposal. In your proposal, we go from merely needing to sort
> out the method namespace in 'x.y', to knowing far, far more about x.y:
>  - The entire variable namespace.
>  - The TYPES of the variables in x.y.

No, I would deliberately make this knowable without knowing the types,
lest we get into exponential memory/time to resolve types.

> Solution:
> c.invoke(args) is the only legal closure invocation syntax. c(args) isn't.
> Is 'invoke' some serious curseword in programmese? Does it offend you so
> that this syntax just cannot stand?

Can you try to read the words?  Nothing I said implied I was offended.

-- 
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson at gmail.com
Google Wave: ricky.clarkson at googlewave.com


More information about the closures-dev mailing list