Method references with types [Re: lambda syntax tutorial]

[Stephen Colebourne]

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