some experiments with Concise Method Bodies

[Stuart Marks]

On 10/15/18 3:01 PM, Stephen Colebourne wrote:
> - On the code changes, I'm not a fan of the desire to line up all the
> arrows. Why do that when that isn't the general style of the JDK? Was
> it to do with readability? What would you do if the code exceeded the
> line length?

If you look at the original source file [1] you'll see that several of the 
method bodies use a "non-standard, compact" style, and they're all lined up:

     public int size()                          {return c.size();}
     public boolean isEmpty()                   {return c.isEmpty();}
     public boolean contains(Object o)          {return c.contains(o);}
     public Object[] toArray()                  {return c.toArray();}
     public <T> T[] toArray(T[] a)              {return c.toArray(a);}
     public <T> T[] toArray(IntFunction<T[]> f) {return c.toArray(f);}
     public String toString()                   {return c.toString();}

This "style" appears to date back all the way to the introduction of Collections 
in JDK 1.2. It occurs several times elsewhere in the same file. I've simply 
copied it in my CMB experiment. There's one case in my experiment [2] where the 
CMB didn't fit on the same line. I moved it to the next line, but indented it so 
that its arrow lines up with the others:

             public boolean hasNext() -> i.hasNext();
             public E next()          -> i.next();
             public void remove()     -> throwUOE();
             public void forEachRemaining(Consumer<? super E> action)
                                      -> i.forEachRemaining(action);

Of course, it's up to you whether you want to line up arrows or equals for CMBs, 
but I think it makes it a bit easier to see what's going on.

> - Part of the driver was about delegation. But was this change
> successful on that measure? There was still redundant code.
> Specifically, you still had the full method signatures that you were
> delegating even though they are inherited from an interface. Method
> parameter names were needed when they didn't matter for example. A
> focussed delegate language change might well look quite different,
> such as (not taking this too seriously...): [...]

I think we need to be careful about "driver" here. My example was about using 
CMB for delegation; but that doesn't mean the "driver" for the CMB feature is 
delegation. I don't see the need to declare success or failure; I reported some 
observations that I hope are useful in deciding whether to or how to continue 
developing the CMB proposal.

It may be that there are some improvements that can be made to CMB that will 
help the delegation case, but I'm not going to advocate for changes that turn 
CMB into a feature centered around supporting delegation.

s'marks


[1] 
http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/util/Collections.java#l1021

[2] http://cr.openjdk.java.net/~smarks/amber/UnmodColl2.java