Method refs [was Re: State of the Lambda]

[Stephen Colebourne]

+1 to all John said on bound and unbound method refs and associated
syntax (# infix).

Java frameworks today have a big need for both forms. Look at the play
framework for one example.

BTW, since method references do not have a denotable type, a useful
addition to the spec for comparibility with older systems would be
target type conversion to j.u.r.Method. I don't believe there are any
complications in doing that. This then strengthens the case for field
references.

Stephen

On 08/07/2010, John Rose <john.r.rose at oracle.com> wrote:
> On Jul 8, 2010, at 12:44 PM, Brian Goetz wrote:
>
>> What I think you are asking for is something like "field references" to go
>>
>> along with "method references".
>
> No, I think he means the difference between the unbound String#length()
> which is of type (String)->int and the bound "myString"#length(), which is
> of type ()->int.  The latter is derived by a partial-application operation
> from the former.  John's example uses the unbound version, while other use
> cases (event handlers, e.g.) would use the bound version.
>
>>     select<Person>({ p ->  p.getName() }, { p ->  p.getAge()
>> }).from(persons)
> =>
>     select<Person>(Person#getName(), Person#getAge()).from(persons)
>
> The method reference Foo#bar() is the basic building block.  The derived
> reference myFoo#bar() starts with Foo#bar() and partially applies the
> receiver argument myFoo.  The binding could be neatly performed by an
> inserted call to MethodHandle.bindTo or an similar static runtime routine.
> The basic unbound method reference could be materialized by a JSR 292
> ldc/MethodHandle, perhaps with a library routine call (asSAM) to wrap it in
> the SAM type.  Compilers would be able to readily optimize the bytecodes
> into one heap node when or if desirable.
>
> -- John
>
> BTW, in my prototype, I made the trailing parentheses *required* precisely
> to leave room for the analogous (but less useful) notion of field
> references.  (Both bound and unbound, both setters and getters: all were
> implemented; see previous reference.)
>
> Requiring the trailing parens makes it slightly more clear that a method is
> being mentioned, since identifier-followed-by-paren is a cue Java
> programmers know very well.  I chose a wildcard-like notation Foo#bar(...)
> to mean "find the unique 'bar' method".  But that's a relatively unimportant
> detail, compared to getting the bound-vs.-unbound distinction right.
>
>