Method references in annotations?

[Dan Smith]

On Aug 9, 2011, at 9:04 AM, Jason Schroeder wrote:

> Thanks for the pointers.  The landscape is clearer and
> past email threads are clearer.
> 
> Once functions can be treated as some fashion of a literal,
> some functional language behavior is immediate.
> 
> To me, the trouble is that those behaviors should be accidents
> instead of goals to keep temptation away.
> 
> Question #1.
> Has the following been considered previously?
> 
> SAM sammy = ...
> Method sammyMethod = Method.convertToMethod(SAM.class, sammy);
> assertEquals(sammy.method(),sammyMethod.invoke(sammy));

This API already exists:
Method sammyMethod = SAM.class.getMethod("samMethodName");

> Question #2.
> It seems the above code pattern could be sugared thusly:
> 
> Method sammyRef = #Person.getLastName
> 
> Treating Method as a SAM, Method.invoke, in order to implement
> a "method of" feature.
> 
> Has that been considered previously?  What was the discussion?

That's a reflection method literal.  Does it make sense to re-use the method reference syntax in this context?  Probably.  But, like I said before, it's likely outside the scope of what Lambda is trying to accomplish right now.  Where this discussion matters right now is we'd prefer not to make decisions that preclude this sort of thing in the future.  A likely evolution path is that we release 8 with the current scope, get some experience with how people use it, and then address things like this in a future iteration if they prove to be compelling enough.

> Question #3.
> The expectations around the use of lambda.this seem, at first blush,
> following the usage of constructor-call this, treating "this" as an
> obvious, but unnamed, function call.
> 
> I believe the above questions are trying to generalize the feature
> to Method.invoke.
> 
> Has this been noted previously?

There are two problems with recursion: how it's expressed, and how it's implemented.

If your suggestion is an implementation strategy, it is one of many possibilities.  A few of the most promising strategies are being considered.  A goal here is that we don't want to force a particular strategy on implementers.

If your suggestion is that, on the "how it's expressed" side, the type of 'this' in the body of a lambda be Method or MethodHandle, our conclusion was that that degree of concreteness would be overly restrictive to the implementation.  A conclusion from discussions on this topic is that it's better to think of a lambda as a block of code, not an object with identity.

—Dan