New JEP: Concise Method Bodies

[Kevin Bourrillion]

On Wed, Sep 19, 2018 at 2:44 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

On 9/19/2018 12:31 PM, Kevin Bourrillion wrote:
> > In other cases, it looks like you're gaining a very /small/ amount of
> > syntactic conciseness (mostly omitting `return`) and not much else? Is
> > there any actual /conceptual/ simplicity or clarity being gained?
>
> Let me focus on the single expression form. The argument we've made is:
> statement lambdas have a concise form, expression lambdas, that improves
> clarity, and method bodies are like statement lambdas, so they should
> have a concise form too.


Okay. I get it. And I think this is the exact sort of parallel structure
argument that reduces conceptual weight of a *new* language design.

I think something very different happens for a language as solidified as
Java. We cannot make it simpler than it is; when we add simpler things,
then people just have to know both the new way and the old way. We can only
ever add complexity.

Arrowform switch is a good example where I think we can all agree that a
certain bar is cleared. It is so broadly applicable and makes code so much
easier to reason about that it manages to pay for itself.

In this case, I think the `=*` *form *might* also clear that bar because of
the automatic parameter pass-through. But I cannot currently see how the
`->` form comes close to clearing it.



> (Data welcome.)
>

Ooh, you know the magic words! Okay, we will analyze cases amenable to the
`=` form, but I don't currently see a reason to gather stats on `->` form
applicability.



> JEPs don't seem to often include any discussion of what the costs of the
> > feature change. So evaluating benefit vs. cost is not easy. For example,
> > in this case, it becomes harder to understand and explain what a method
> > reference even /is/. I've been saying "it's just a lambda expression",
> > but either that's gone, or it's now becoming harder to understand and
> > explain what a lambda expression is.
> >
> > I think moral-hazard arguments also deserve a bit of thought.
> >
> >    public A b(C c, D d, E e, F f) { return g.h(c, d, e, f); }
> >
> > If I forgot an "if e is empty, throw" check in here, I'll just insert
> > it. But if it was this:
> >
> >    public A b(C c, D d, E e, F f) = g::h;
> >
> > I'm probably less likely to do that.
> >
> > This is a bit similar to why our style guide requires braces around
> > single-statement if blocks. It's too annoying to deal with inserting
> > them and removing them all the time as conditions change.
> >
> > Perhaps these costs don't add up to anything massive, but we should
> > still get a fix on them because if it turns out the benefits
> > /also/ don't add up to something massive then....?
> >
> > I hope this is helpful.
> >
> >
> > On Wed, Sep 19, 2018 at 11:58 AM <mark.reinhold at oracle.com
> > <mailto:mark.reinhold at oracle.com>> wrote:
> >
> >     2018/9/19 11:42:16 -0700, alex.buckley at oracle.com
> >     <mailto:alex.buckley at oracle.com>:
> >      > https://bugs.openjdk.java.net/browse/JDK-8209434
> >
> >     Or, more readably: http://openjdk.java.net/jeps/8209434
> >
> >     - Mark
> >
> >
> >
> > --
> > Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com
> > <mailto:kevinb at google.com>
>


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180920/90e74fad/attachment-0001.html>