[foreign-memaccess] RFR 8231402: layout API implementation is not constant enough

[Maurizio Cimadamore]

For the records - the rationale behind MemorySegment::slice (and also 
asReadOnly...) was driven by familiarity with ByteBuffer API. That is, 
these concepts exist in the BB API with precisely those names, so I 
thought it might have been better not to reinvent the wheel (given that 
I can see people currently using BB for off-heap usages looking at this 
API).

Maurizio

On 24/09/2019 22:14, John Rose wrote:
> On Sep 24, 2019, at 12:56 PM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>
>>> The view factories seem to have a naming inconsistency; there is 
>>> `asPinned` and `asReadonly`, but `slice`.  Given the slightly odd 
>>> treatment of views when it comes to temporal bounds, I would prefer 
>>> the asXxx (which suggests you're going to use the view in place of 
>>> the original) form, and suggest `asSlice` or `asNarrowed`.
>> Good point - yes, the slice is a view and all views should use 
>> uniform naming.
>
> Not to go crazy at the bike shed, but it seems to me that spatially 
> narrowed views are
> special enough to merit their own intuitive terminology, in the same 
> way that
> List has just subList and not asSubList/asSlice.  After all, the 
> contiguous ordering
> of a segment of memory is probably its most salient property, and so 
> slicing
> is one of the most fundamental operations.  The access modes (tweaked by
> asReadOnly) and the temporal properties (tweaked by a scope API and/or
> view operations like asPinned) are less salient and don’t deserve special
> terms.  (List has very limited view-constructors, but omitting subList 
> is hard
> to imagine.)
>
> Also, unlike most view creation operation, the slice creation API has two
> degrees of freedom, and they vary over the whole datum being sliced.
> Most view creators (think Array.asList) re-interpret the *whole* datum
> with minimal configuration parameters.  The effect of this can be seen
> by imagining the bikeshed color "asSubSegment” ("asSubSequence”,
> etc., as appropriate).  How does that sound?  It sounds wrong IMO,
> because the “as” part sets you up to look for a view, but then the “sub”
> part doesn’t parse, since no “foo” is alias-able to a “sub-foo” of itself.
> (The whole is greater than the part; Cantor’s pairing constructions, etc.)
> So a sub-foo is a little like an alias of a foo, but only *part* of a foo.
> Calling the sub-foo a “view” of a foo drops the most important fact,
> the part/whole distinction.
>
> So, my only objection to “slice” might be that it sounds like a verb 
> where a
> noun is probably preferable (but it’s a noun also, which is why I 
> don’t find
> it too difficult).  I think a bikeshed color like “subSegment” or 
> “makeSlice”
> is a better alternative to “slice” than “asSlice”.
>
> I promise to put away my spray paint now.
>
> — John