[foreign-memaccess] RFC: remove CompoundLayout and PaddingLayout

[Brian Goetz]

>>
>> The treatment of unbounded sequences seems iffy.  If Layout::elements 
>> might return an unbounded sequence, and there is no way to ask "are 
>> you an unbounded sequence", what is the utility of calling 
>> Layout::elements?  I get I might want to grovel through _named_ group 
>> elements, but an infinite stream of the same layout doesn't seem like 
>> anything I'd ever want to get.  Similarly, what should elementsSize() 
>> return when I have an unbounded sequence?  I have factories for both 
>> bounded and unbounded sequences, but then I can't really tell the 
>> difference between them.  I think some rationalization here is needed.
> I believe elements() is mostly there as an attempt to unify group and 
> sequence (a dream we had back then). I think with this API we can 
> probably live w/o elements(). If you really want to access to 
> sub-elements, down-cast to the right layout (e.g. GroupLayout) and 
> access elements from there (GroupLayout::elementAt(long)). Deal?

I think that's probably right.  Still, having some way to tell a 
Sequence is unbounded is useful, either an isUnbounded() method or a 
distinguished value for elementCount() that means "unbounded". 
Otherwise, constructing a sequence becomes a lossy operation, in that 
you can't recover how it was constructed.

>
>>
>> Add comments to the effect that PathElement, *Layout, and 
>> MemoryAddress are value-based.
> I believe I did this for most of the classes - but might have missed 
> some - will double-check

Also, consider making the appropriate ones Constable eventually.

>>
>> I know this is a can of worms, but given that layouts for, say, 
>> 32-bit int in native bit order will be super-common, I'd prefer to 
>> have constants for these rather than calling the factories over and 
>> over.
>
> Yep - this depends quite a bit on what we decide to do with respect to 
> endianness. That is, we can have an UINT32 constant, but what is the 
> endianness? This is a problem we also had in mainline Panama/foreign 
> branch.
>
> Overall I agree that users will want to work with constants, rather 
> than with factories - so we need to find some compromise in that area, 
> and come up with a good set of constants. 

Let's just bear in mind that we can think of at least three categories 
of users, each of which will have different ideas about endianness:

  - Traditional FFI users.  These folks are calling native methods, and 
dealing with native layouts.  Some of the time, these folks don't care 
about endianness, but sometimes they do -- such as if they are laying 
out a network packet.  They want the ability to control endianness, but 
probably want simple defaults.

  - "Pure" Java off-heap users.  These folks are using off-heap memory 
strictly to sidestep the GC and runtime; the data is never leaving the 
machine.  They aggressively don't care about endianness, and will hate 
you if you make them think about it.

  - Java interop users.  These folks are doing things like protobuf, 
which by definition is leaving the machine.  These guys need explicit 
control over endianness all the time.

There might be others too!  I guess my plea here is: don't sacrifice the 
"Pure" java users for the sake of the others.  There needs to be an easy 
way to say "Java primitive int please, with all that entails", and not 
get wrapped up in bit sizes, order, etc.