Field and Method Literals

[Collin Fagan]

*Adding or removing formal parameters of that method will break the
compatibility.*

Isn't this almost always the case? I'm having a hard time understanding why
it's any worse to break an annotation then any other line of code.

But more to the point what is Chris actually asking for? Is it just to be
able to use static method references with annotations?

Collin

On Sun, Apr 17, 2011 at 10:52 AM, Rémi Forax <forax at univ-mlv.fr> wrote:

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