m.invoke() vs. m()

[Ricky Clarkson]

Whereas the only interpretation that actually makes sense is to choose
the closest in lexical scope.  In other words, f.invoke(args) and
f(args) should never do different things to each other if you support
the latter as shorthand for the former, unless you're deliberately
making a language hard to follow.

That is just as backward compatible, as no existing code contains
closures, so no existing code's semantics is altered.  I don't quite
know what migration compatible means; I guess it's a woolly term.

2009/12/5 Reinier Zwitserloot <reinier at zwitserloot.com>:
> Yes, I presumed Mark screwed up on that. The repercussions of being able to
> invoke any variable of a closure type simply by tossing parentheses after
> its mention are rather staggering. The closest you can get to something that
> is backwards and migration compatible and doesn't completely change the
> entire language is something like:
> when the parser sees something of this form:
> identifier(argslist[opt])
> the parser will consider this a MethodCallOrClosureInvocation.
> During resolution, if identifier refers to a method name that is in scope,
> then this is a method invocation. If there is no such method name but there
> is a variable with that name, then it is a closure invocation.
> Meaning, if you create a new method, or one of your supertypes adds a new
> method, or something is statically imported, then a closure invocation can
> silently turn into a method invocation.
> The fun quadruples when you try to add some rule to the tune of: if
> 'identifier' is a legal method but the argslist doesn't fit any of that
> method's overloads, but it does fit the closure, then presumably, execute
> the closure instead. Yich.
> That's rather a lot of dancing the parser/resolver has to do in an area
> that's already extremely complicated (method resolution), all to avoid
> having to write '.invoke' in there. I'm not a fan of frivolous syntax merely
> to highlight something that your IDE can already tell you (that 'identifier'
> is a variable with a closure type), but in this case, the '.invoke' actually
> does impart something of significance that your parser/IDE cannot always
> infer for you: That the thing to the left of the invoke is a variable and
> not a method name.
>
> --Reinier Zwitserloot
>
>
>
> On Sat, Dec 5, 2009 at 1:33 PM, <tronicek at fit.cvut.cz> wrote:
>>
>> Hi,
>>
>> I noticed a discussion about m.invoke() and m() on Mark Reinhold's blog
>> and although it is true that if m is in the variable name space, we need
>> "invoke", if syntax
>>
>> fun void m(int x);
>>
>> is adopted, it seems natural to have m in the method name space and then
>> the "invoke" is not needed.
>>
>> Z.
>> --
>> Zdenek Tronicek
>> FIT CTU in Prague
>>
>>
>>
>>
>>
>
>



-- 
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