[foreign-memaccess+abi] RFR: Add support for high-level functions to copy to and from Java arrays [v5]

[Maurizio Cimadamore]

On 24/06/2021 19:52, Lee Rhodes wrote:
> The conceptual model I had in mind when I proposed this API was that it seemed sensible to order the parameters first by the data flow: {source parameters, destination parameters}, then by {Object, offset, length} with ByteOrder stuck at the end. Thus:
>
> - copyToArray(srcSegment, srcOffsetBytes, dstArray, dstIndexChars, dstCopyLengthChars, order);
> - copyFromArray(srcArray, srcIndexChars, srcCopyLengthChars, dstSegment, dstOffsetBytes, order);
>
> But this is by no means the only mental model we could use as this {source, destination} flow model is not consistently followed even within the current FMA API.
>
> As an alternative, we could use the conceptual model of {segment parameters, array parameters}. Thus:
>
> - copyToArray(srcSegment, srcOffsetBytes, dstArray, dstIndexChars, dstCopyLengthChars, order);
> - copyFromArray(dstSegment, dstOffsetBytes, srcArray, srcIndexChars, srcCopyLengthChars, order);
>
> For the user, this model has the parameters by type always in the same order, the length (and order) are at the end, and because of that the prefixes for the copy length could probably be dropped.  But I would prefer to keep the other prefixes as they are as additional cues to the user of the flow direction as well as association.

Honestly, it's not clear to me how the conceptual model is affecting 
where the length parameter goes. What I object to (and John and Jorn 
seems to agree) is that the "length" is not associated with either 
inputs - it's just a length, which can be expressed in bytes or in elements.

So:

- copyToArray(srcSegment, srcOffsetBytes, dstArray, dstIndexChars, numChars, order);
- copyFromArray(srcArray, srcIndexChars, dstSegment, dstOffsetBytes, numChars, order);

or

- copyToArray(srcSegment, srcOffsetBytes, dstArray, dstIndexChars, numChars, order);
- copyFromArray(dstSegment, dstOffsetBytes, srcArray, srcIndexChars, numChars, order);

Depending on how the other parameters should be sorted. I personally prefer:

* source first
* destination second
* length last (and order after that)

(which means the first of the two proposal above).

As John says, that's how System::arrayCopy (and many other libs) do it, 
I don't think I see the need for going down another path.

Is there a specific concern you have against that?

Cheers
Maurizio