[foreign-memaccess] RFR 8231402: layout API implementation is not constant enough
John Rose
john.r.rose at oracle.com
Tue Sep 24 22:10:34 UTC 2019
That’s another good point for slice. Note however that asSubList is a more modern API point than BB.slice.
> On Sep 24, 2019, at 3:08 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>
> 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> 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
More information about the panama-dev
mailing list