Method references with types [Re: lambda syntax tutorial]

[Paul Benedict]

Good point Stephen. Parentheses should refer to methods, and without them to
fields. Your insight will definitely retain the separate namespaces that
Java has established.

PS: Is Lambda also considering any support to turn method/field references
into java.lang.reflect types?

On Thu, Aug 5, 2010 at 2:57 PM, Stephen Colebourne <scolebourne at joda.org>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.
> >
> >
> >
>
>