State of the Lambda

[John Rose]

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.