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

John R Rose jrose at openjdk.java.net
Thu May 14 20:50:04 UTC 2020

On Thu, 14 May 2020 15:48:48 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> @mcimadamore I really like this suggestion (instance methods on MemorySegment). Especially given unchecked memory
>> addresses, your proposal to move `copy` to `MemorySegment`, will result in the API point being more obviuosly correct
>> by design ( less potential to use incorrectly ). And as you mention, we probably want to get this right now, since
>> `mismatch` is next on my todo list ;-) ( And mismatch will not work on unchecked addresses )  This design assumes
>> slices are relatively cheap, given that more slicing will be needed to interact with API points, but that should
>> probably be ok.
> 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.


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

More information about the panama-dev mailing list