Field and Method Literals

[Rémi Forax]

It's more a discussion for lambda list.

On 04/17/2011 10:35 AM, Chris Beams wrote:
> Stephen's comment reflects our concern - that method literal support limited to or designed for lambda contexts does not go far enough.  The "State of the Lambda" document linked below uses the following example for static method literals:
>
>
> Arrays.sort(people, #Person.compareByAge);
>
>
> Then goes on to differentiate syntax for instance method literals:
>
>
> Arrays.sort(people, #comparatorHolder.comparePersonByAge);
>
>
> The proposal for static method syntax would be fine for our purposes, but the the proposal for instance method syntax assumes that a receiver variable (comparatorHolder in this case) is available in the first place.  For Spring's purposes, this would invalidate a number of use cases, and rules out use within annotations entirely.

Using static method references in annotation is not a good idea
because you will tie your specification (the annotation) to one 
implementation (the code of the method reference).
Adding or removing formal parameters of that method will break the 
compatibility.
An annotation must be loosely couple to its implementation, it's the 
only way to garantee implementation evolution.

> We're looking for a general purpose constant-expression method literal syntax usable in any programmatic context and that may refer to any type of method.
> We particularly care about usability within annotations, thus the necessity for evaluation as constant expressions.

Annotation expression is defined as a subset of all expressions.
So it can be limited to constant method reference but again it's bad(tm) 
to use it in an annotation.

>   Toolability is also key - for example, Eclipse users should be able to hit 'F3' on the use of a method literal and arrive at its associated method declaration, just as doing the same on a class literal opens the class declaration. Such support would be straightforward for tool vendors to implement.

Agree.
It should not be hard knowing that one IntelliJ guy and one Eclipse guy 
are in the expert group and
that the reference implementation is javac which is used by NetBeans.

> Method (and field) literals seem to me an obvious addition to the language; I've often wondered why they weren't there from the beginning, just as class literals have been.

Class literal was introduced in 1.1 and really supported by the VM in 1.5 :)

>   Is there a theoretical reason why they should not or cannot be introduced?  I would think they are more fundamental than any closure proposal, and that closure proposals would build atop field/method literal support as opposed to the other way around.

Currently they are not built atop but both lambda and method reference 
share the same underlying mechanism.
A lambda is almost an anonymous method reference (if you forget 
serialization).

> - Chris

Rémi