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

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Fri Feb 1 01:00:01 UTC 2019


On 01/02/2019 00:51, John Rose wrote:
> On Jan 31, 2019, at 3:41 PM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>
>> Can I suggest that, from a logistical point of view, we split the 
>> original changeset from the static import discussion?
>>
>> Which kind of imports we need in practice is a question that will be 
>> much better answered by looking at concrete use cases, and using the 
>> API in anger, rather than trying to abstractly find the best possible 
>> split.
>>
>> Also, where to put these extra constants depend, in my view, on what 
>> we do with SystemABI - if that would to become a public type, I think 
>> that would be a natural place where to put some of these.
>
> I think you are asking for the explicit naming of things but to hold
> off on the factoring into importable bundles.  That's OK, except the
> Henry's change introduces something called INT16 which has exactly
> the properties I'm trying to avoid:  It implicitly incorporates a variable
> parameter into its meaning without signaling the fact.

I'm saying make everything explicit - and drop INT16 at least for now, 
for either LE_INT16, or some other scheme.

Maurizio

>
> So, I'm OK with deferring some of the class design, as long as the first
> changeset avoids the bug I'm talking about.  To do this, the name
> INT16 is insufficient.   A name like PLATFORM_INT16 or PE_INT16
> would be fine with me.
>
> — John
>


More information about the panama-dev mailing list