Named lambdas (was Re: Serialization stability and naming (and syntax))

[Brian Goetz]

In both cases we would still have to deal with ambiguity, which is worse in the method param case.  

Sent from my iPhone

On Oct 12, 2012, at 3:54 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> We can use the name of the parameter of the method. The parameter name is stored in the bytecode by java 8 and available in local variable table (if the symbols are not striped) if the bytecode version is < 8
> 
> Rémi
> 
> Sent from my Phone
> 
> ----- Reply message -----
> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Kevin Bourrillion" <kevinb at google.com>
> Cc: <lambda-spec-experts at openjdk.java.net>
> Subject: Named lambdas (was Re: Serialization stability and naming (and	syntax))
> Date: Fri, Oct 12, 2012 16:33
> 
> 
> I assume you're talking about lambda names now, and not recursion?  
> 
> If so, this works for lambdas assigned to locals but not to lambdas passed to methods.  
> 
> On Oct 12, 2012, at 3:06 PM, Kevin Bourrillion wrote:
> 
>> Huh. Can it be that simple? This works for me if no one else sees a problem with it!
>> 
>> 
>> On Tue, Oct 9, 2012 at 10:30 AM, Dan Smith <daniel.smith at oracle.com> wrote:
>> The approach we settled on for names for recursive lambdas was to use the targeted variable name:
>> 
>> IntOp fact = x -> {
>>   if (x == 0) return 1;
>>   else return x*fact.apply(x-1);
>> };
>> 
>> That also seems like a useful, unobtrusive way to give a lambda a name for debugging.  If somebody cares about readable names for debugging, they'll probably also care about readable names in code, and the way you name something in code is assign it to a variable.
>> 
>> Of course there will be cases where we'd need the name to be "fact$2" or something, but for a best-effort problem like debugging hints, that seems good enough.
>> 
>> —Dan
>> 
>> On Oct 9, 2012, at 9:40 AM, Kevin Bourrillion <kevinb at google.com> wrote:
>> 
>>> Okay, so the benefits of user-provided names seem to be
>>> 
>>> - More readable toString and stack traces than the auto-provided name (lambda#8 or whatever)
>>> - A very small (as noted by Brian) potential to make serialization usable across code changes in a few more situations
>>> - It should apparently help hot-swapping to be usable in a few more situations
>>> 
>>> Anything else?
>>> 
>>> If we come up with some syntax for users to name individual lambda expressions, do we think these benefits are great enough that enough users will name their lambdas enough of the time to get real benefit?  I'm unsure.  Even though lambdas are way more concise than classes, this supreme terseness of lambda expressions is sort of intoxicating and I wonder if most users will get drunk on that and not want any extra characters that weren't strictly required.
>>> 
>>> Likewise, to the extent that any of the advantages can also be realized by switching to a method reference, do we think enough users will actually be willing to make that switch?
>>> 
>>> 
>>> On Sun, Oct 7, 2012 at 11:44 AM, Andrey Breslav <andrey.breslav at jetbrains.com> wrote:
>>> I would like to point out one thing that somehow keeps escaping our discussions of this matter.
>>> 
>>> Although for some people serialization is the biggest concern here, for a lot more people a much bigger concern is hot-swapping, where name stability is very important as well.
>>> 
>>> In my mind, this requires us to reconsider the arguments for having/not having stable names/signatures where we could have that.
>>> 
>>> --
>>> Andrey Breslav
>>> http://jetbrains.com
>>> Develop with pleasure!
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
>>> 
>> 
>> 
>> 
>> 
>> -- 
>> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
>> 
>