Method references in annotations?

[Dan Smith]

Discussions along the lines of "yeah, those are things we should get to sometime" have happened here, internally at Oracle, and in the JSR 335 expert group.

If you'd like to take that to the next level, that's certainly something you could do.  Patches, forks, and in-depth proposals are all useful ways to collaborate, and can have a significant impact on future SE work (this project and JSR 308 are good "big" examples).  That said, I think the biggest challenge here is not coming up with a cohesive story, but rather convincing the relevant stakeholders that a proposed story is the *right* one.  That aspect is not something I envision being facilitated much by external collaboration.

—Dan


On Aug 10, 2011, at 11:57 AM, Jason Schroeder wrote:

> I am here to shoulder some of the work not randomize you.  My
> questions were the wrong ones with which to start.
> 
> Rather, if there is need for a cohesive story about the original list
> of four distinct but overlapping concerns, is it happening on this
> list?  Regardless if it is the lambda project's goal to implement it.
> Is the lambda where those topics should collect?
> 
> What I am thinking to do is to fabricate changes to present a unified
> story.  Are others doing this?  Is this a waste of time?
> 
> On Wed, Aug 10, 2011 at 12:39 PM, Dan Smith <daniel.smith at oracle.com> wrote:
>> 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
>> 
>>