[foreign] RFR 8218153: Read/Write of Value layout should honor declared endianness

[Henry Jen]

On Feb 26, 2019, at 4:07 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> 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())
> 

With an critical condition that endianness.isEmpty(), thus I think better to be explicit API rather than wirhEndianness(), which will override endianness.


> 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.
> 

OK. But then we don’t have way to switch endianness, but that’s probably not much a valid use case?

> 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