Method references with types [Re: lambda syntax tutorial]

[maurizio cimadamore]

On 05/08/2010 22:31, Mikael Grev wrote:
> A really clear version would be
>
> #Foo.bar(...)
>    
That variant has also been considered - it has the clear advantage of 
not being ambiguous w.r.t. no-arg method references.

Maurizio
> Expressing clearly that anything goes as parameter.
>
> On Aug 5, 2010, at 23:08 PM, Brian Goetz wrote:
>
>    
>> It has been mentioned, but only on whiteboards so far :)
>>
>> We are for this reason considering #foo.bar() instead of #foo.bar.  We are
>> also considering a greedy prefix syntax instead of infix.
>>
>> On 8/5/2010 3:57 PM, Stephen Colebourne wrote:
>>      
>>> No one has yet mentioned another danger with using Foo#bar instead of
>>> Foo#bar(String).
>>>
>>> The former choice at this point closes off options in the future for Java.
>>>
>>> Foo#bar is the only sensible syntax for a field literal. Java can have
>>> both fields and methods with the same name. This has the potential to
>>> be a limitation to future language development.
>>>
>>> If there is a positive decision here today that field literals will
>>> never be added (and that any future property literals will never
>>> clash) then fine, but that seems like a strong statement at this
>>> point.
>>>
>>> Stephen
>>>
>>>
>>> On 5 August 2010 19:08, Nathan Bryant<nathan.bryant at linkshare.com>   wrote:
>>>        
>>>> Kevin Bourrillion wrote:
>>>> Ø  For example, if Foo#bar has no contextual smarts at all, then adding overload #2 of any method would always be source-incompatible (which would be hideous!).  So how much intelligence does it have?
>>>>
>>>>
>>>>
>>>> The worst-case of overloading always producing breakage can be ruled out; the set of possible overloads can only include those that have SAM types that are compatible with any of the overloads of Foo#bar .
>>>>
>>>>
>>>>
>>>>  From there, resolution should proceed in the usual way (most specific wins, or else the programmer must disambiguate.)
>>>>
>>>>
>>>>
>>>> In order for the worst ambiguities to arise, Foo.bar and the target method must both be overloaded. Is this really that common of a case? Any lesser ambiguities are the ones that can also arise with the lambda parameter type inference that is already implemented.
>>>>
>>>>
>>>>
>>>>          
>>>        
>
>