<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>De: </b>"Kevin Bourrillion" <kevinb@google.com><br><b>À: </b>"Alex Buckley" <alex.buckley@oracle.com><br><b>Cc: </b>"amber-spec-experts" <amber-spec-experts@openjdk.java.net><br><b>Envoyé: </b>Vendredi 5 Octobre 2018 22:25:28<br><b>Objet: </b>Re: New JEP: Concise Method Bodies<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr">Oops - sorry for the rapid-fire responses here. A couple more points while this is all still actively rattling in the brainpan.<br><div>Today, method references are a thing, and can be bound to expressions:  `foo()::bar`.</div><br><div>A piece of folk knowledge that we count on developers to pick up along the way is that the `::` separates that which is evaluated now from that which is evaluated later. Any who don't grasp that will eventually get into some trouble sooner or later.</div><br><div>Now we want to introduce a second way to use method references, where that creation/evaluation distinction doesn't exist. Or does it? <i>Some</i> number of users will think "maybe what's before the :: is evaluated the first time the method is called and then reused? In fact, I think I remember learning something just like that... they were really clear about the difference between what's before vs. after the ::. This must be it." This is problematic.</div><br><div>Finally, to my earlier screed about the trade-offs of "multiple ways to do the same thing" I want to add a nice (very paraphrased) point that was made on reddit by a now-deleted account. (Thanks, mystery person.) Offering users a choice between two ways to do the same thing isn't <i>just</i> offering them a choice. It's also burdening them with having to read and maintain code that made each of those choices, for whatever reasons that may be unknowable now. Now, no one in amber-spec-experts will say "I never thought of that before", but I'm just explaining why I'm advocating for a high bar here.</div></div></blockquote><div><br data-mce-bogus="1"></div><div><devil-advocate><br></div><div>but we have method ref and lambda as expression since Java 8, two ways to do the same things ?<br data-mce-bogus="1"></div><div></devi-advocate><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>As expression, method ref are useful compared to lambda because<br data-mce-bogus="1"></div><div>- you name things i.e. if the code is more meaningful than a name, use a lambda, if a name is more meaningful, use a method ref<br data-mce-bogus="1"></div><div>- the operator :: is the real operation, a lambda is just a syntactic sugar for an anonymous method ref.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>With the concise method body, a method ref is is<br data-mce-bogus="1"></div><div>- convenient way to express delegation.<br data-mce-bogus="1"></div><div>- the lambda is the way to express a concise body, the method ref is conceptually a sugar way to express a lambda</div><div><br data-mce-bogus="1"></div><div>the main difference is that the method ref syntax for concise method body still requires to write the types of parameter types, so while method ref is useful as an expression because you can choose if you want to name things (method ref) or don't (lambda), it seems there is no such rational for method ref for concise method body compared to a lambda, it seems more like a kind of gimmick.</div><div><br data-mce-bogus="1"></div><div>and there is still the issue that the '=' between the method declaration and the method ref is not an assignment too. </div><div><br data-mce-bogus="1"></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><br><br><br><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 5, 2018 at 1:03 PM Kevin Bourrillion <<a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Sep 24, 2018 at 10:17 AM Alex Buckley <<a href="mailto:alex.buckley@oracle.com" target="_blank">alex.buckley@oracle.com</a>> wrote:<br></div><div dir="ltr"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 9/21/2018 4:07 PM, Kevin Bourrillion wrote:<br>
> "The method reference form can use most kinds of method references after<br>
> the = sign: static and unbound method references, bound method<br>
> references (if the receiver *variable* is in scope for the method<br>
> declaration)"<br>
><br>
> Can we still bind to any expression?<br>
><br>
>    private String a(String b, int c)<br>
>        throws SomeCheckedException = *d.e()*::f;<br>
<br>
No limitation is intended on the receiver, as long as the method <br>
reference expression would be legal if it appeared in the traditional <br>
body of method `a`. (Details of this translation remain to be worked out.)<br></blockquote><br><div>Can the expression before the :: refer to any method parameters? Of course, it would still expect to pass those parameters into the method, so it's <i>weird</i> to have the same parameter used in both ways, but does it make sense to forbid it?</div><br><br></div>-- <br><div dir="ltr" class="m_-4636401784947543106gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"><a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span><br data-mce-bogus="1"></div></div></div></div></div></div></div></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"><a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span><br data-mce-bogus="1"></div></div></div></div></div></div></div><br></blockquote></div></div></body></html>