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

[Dan Smith]

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
>