call operator and orthogonality with existing VM internals

[Neal Gafter]

On Tue, Mar 9, 2010 at 4:23 AM, Jakob Praher <jp at hapra.at> wrote:
>> o The ability to 'shortcut" the call operator x.call(e) as x(e) raises
>> some difficult issues with name lookup that have not yet been solved,
>> which is why a different syntax is being considered.
>
> Do you have any details on that?

The name lookup issues have been discussed on this list, so you'll
find some details in the archives.  To summarize, in an expression
x.y(z), the name y is looked up from among the method names of x's
type.  That means a field named y won't be found.  We cannot change
that in a way that changes the behavior of existing programs.

> I think another interesting idea would be that if an interface only declares
> one public method this public method name does not have to be used as a
> designator for the method call:

That would break existing programs, because some existing program
could have both a method named r and a field named r of type Runnable.

> o Functions as interfaces is one option explored in detail in BGGA.
>>
>> The alternative of using MethodHandle is being considered for project
>> lambda.
>
> What is your opinion on that? My motivation for functions as interface types
> is out of syntactic taste.

I think either one is a viable option, though some changes to
MethodReference are required (to support variance) before they can be
used for this.

> When should one function be subtype of another funciton?
> Does covariancy is an issue for that? Something like that is also harder to
> express with interface types.

BGGA manages to handle function types with covariant returns and
contravariant argument types by treating then as instances of generic
interfaces using wildcards.