[foreign-jextract] RFR: Add MemoryLayout::byteOffset

[Maurizio Cimadamore]

On Mon, 11 May 2020 09:51:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi,
>> 
>> As part of feedback on the Foreign Memory API (when experimenting with
>> its usage internally in the JDK), a small number of potential usability
>> enhancements could be made to the API. This is the first such.
>> 
>> This change:
>>  1) renames MemoryLayout::offset to MemoryLayout::bitOffset, and
>>  2) adds MemoryLayout::byteOffset
>> 
>> This allows for easier interoperation with MemoryAddress, which deals
>> with offsets and lengths in terms of bytes (rather than bits), e.g.
>>    addr.addOffset(layout.byteOffset(groupElement("foo")))
>> 
>> This brings a nice symmetry to the API; there is a trio of bit-wise
>> methods: bitAlignment, bitOffset, bitSize, and their matching byte-wise
>> counterparts; byteAlignment, byteOffset, byteSize.
>
> Looks very good - many thanks!

> This reminds me something I meant to bring up awhile ago: it would be
> nice to have a counterpart method "ofPaddingBytes" and pre-defined
> layouts like "PAD_BYTE_1" to the existing Bit based versions.

Right now all factories take bits (not bytes) as input, as that's more "primitive" and scales more to things like
packed layouts. That said, I see your point. My feeling is that layout construction typically happens once, and then
information is derived from the layout. When you construct you don't care much whether to use bits or bytes (other than
for stylistic preferences) - but when you access layout information, you might be interested in getting either bits or
bytes out, depending on which code you might need to interact with. So, in my view, fixing methods like "offset" takes
the priority here. We'll keep evaluating against use cases and see how annoying that is. Thanks for bringing this up.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/157