[foreign-memaccess] [Rev 01] RFR: Add MemorySegment::fill

[Chris Hegarty]

On Thu, 14 May 2020 20:47:44 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Shifting over `copy` to an instance method on `MemorySegment` so it can be with its friend `fill`, is i think the right
>> move. Other friends can join later.
>> For arrays we never really had any choice (static vs. instance), although i still hold out hope someday we can make
>> arrays implement a richer array'ish interface.
>
> As you might guess from my leading comments, I very much like the idea of
> putting side-effecting fill and copy methods onto MS, not statics as in ju.Arrays.
> Using instance methods instead of static methods helps the reader make a
> mental model of "where it all happens" — in the receiver of the method.
> 
> The problem with static methods is all the arguments "look alike", and so
> there's a perennial problem of deciding which is the source and which is
> the sink.  This is not an issue with `fill` since you know the scalar is the
> source, but it's a big problem with `copy` (cf. `System.arraycopy`).
> 
> If a MS has a utility method for sending data somewhere else, it shouldn't
> be called `copy` but rather `copyRange` (as in ju.Arrays) or `copyOut`
> or `copyTo`.  I have a very mild preference for `copyFrom` for the normal
> polarity of a copy, which copies into the receiver, but that would tend to
> drag in `fillFrom` or `fillWith`, which looks like overkill.
> 
> My $0.02.

The instance method ( for `fill` ) feels much more intuitive ( as can be seem from the test updates ). The moving and
renaming of copy will be done in a subsequent PR.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/161