[foreign-memaccess] [Rev 01] RFR: Add MemorySegment::fill
chegar at openjdk.java.net
Fri May 15 09:32:10 UTC 2020
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.
More information about the panama-dev