[foreign-memaccess] RFC: remove CompoundLayout and PaddingLayout

[Maurizio Cimadamore]

Hi,
over the last few days I've been discussing the existing memory access 
API with Brian (thanks!). While the overall feedback was positive (we're 
moving in the right direction!), Brian raised a couple of interesting 
points:

* the PaddingLayout abstracton is super thin - there's no method in 
there - virtually can be a factory on Layout (e.g. Layout.ofPadding)

* while the lambda approach for creating layout paths is clever, there 
are some issues with it:

- methods like dereferenceHandle are only on ValueLayout or 
CompoundLayout. If the user has a variable of type Layout (likely!) 
those won't work. This creates some friction

- having a lambda chain here prevents features such as compile-driven 
constant folding (JEP ...) to be able, in the future, to spit out these 
constants

* the CompoundLayout abstraction seems also a bit 'thin'. Yes there are 
three methods in there, but there's no method in there that 'screams' 
for having its own abstraction (e.g. the elements() method can easily 
return an empty stream when invoked on a value/padding layout).


We went a bit back and forth, and landed on a slightly different place 
which, usability-wise doesn't lose anything from the previous model (in 
fact, I think it gains something) and, in terms of API simplicity and 
discoverability is much improved.

Here are the basic moves:

- move _all_ layout factory methods into Layout - users will find it 
easily there

- drop PaddingLayout (this is almost a slamdunk)

- replace the lambda-based layout path mechanism with something more 
explicit: we introduce a Layout.PathElement interface and then we rewire 
the dereferenceHandle and offset methods to accept a 'varargs' of these. 
So instead of this:

groupLayout.dereferenceHandle( int.class, path -> 
path.sequenceElement().groupElement("foo"))

the new API lets you do this:

groupLayout.dereferenceHandle( int.class, PathElement.sequenceElement(), 
PathElement.groupElement("foo"))

It's not terribly different, but note two advantages:

* no lambdas, so constant folding will work (when ready)

* this form degenerates nicely to 'zero' path elements, which is 
amenable to be used for ValueLayouts - e.g.

valyeLayout.dereferenceHandle(int.class)


With this move, I could move all CompoundLayout members up to Layout, 
and still get an API that makes sense.

Here's the new javadoc:

http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc_v4/javadoc/jdk/incubator/foreign/package-summary.html

And here's the associated webrev:

http://cr.openjdk.java.net/~mcimadamore/panama/compound_layout_removal/

Thoughts?

Maurizio