[foreign] RFR 8218153: Read/Write of Value layout should honor declared endianness
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Feb 27 00:07:23 UTC 2019
On 26/02/2019 23:49, John Rose wrote:
> On Feb 26, 2019, at 3:19 PM, Henry Jen <henry.jen at oracle.com> wrote:
>> Also added a test and localizeLayout() for group layouts, and a Util method when we need to convert no-endian to explicit endianness.
> If localizeLayout is useful as a public API point it should be on the interface.
>
> If not, it should be package-private or static in Util.
Actually - I was thinking about this: we have a 'withEndianness' in
Value - I wonder if withEndianness should be in Layout (the root), and
have @Overrides which do the right thing.
At which point, localize(Layout) can be simply expressed as
Layout::withEndianness(Endianness.hostEndian())
I'd suggest that withEndianness should alter endianness of existing
layouts which do *not* have endianness, but should throw when changing
endianness of something that already has an endianness of a different
polarity.
That is, this is a tool/API to add endianness info 'after the fact',
which is useful especially when writing Layouts programmatically:
Sequence seq = Sequence.of(
Group.ofStruct(
Value.ofSignedInt(32),
Padding.of(8)
Value.ofFloatingPoint(32),
), 20); // [ 20 [ i32 x8 f32 ] ]
Now, one way to add endianness would be to add explicit endianness to
every Value factory call, but you can see how in composite layouts
there's a risk this might not scale well - what, as the user, I'd like
to be able to do, is just:
Sequence seq = .... some complex layout creation ...
.withEndianness(Endianness.LE);
And that will give me what I want - which preserves the readability of
the original code, and the correctness of having explicit endianness
everywhere, at the expense of creating a bunch of extra garbage for the
GC which should hopefully be able to handle w/o too many headaches :-)
Maurizio
>
> In the present form, it seems like implementation is poking irregularly out of the API.
>
> — John
More information about the panama-dev
mailing list