Additional mismatch overloads for memory segments

[Alexander Biryukov]

> That's why I'm trying to uplevel the discussion a bit: if storing a
MemorySegment
> and an associated long offset is a common enough operation in certain
contexts,
> and we want to support that use case, then we need to pick a solution
that's consistent about it,
> rather than speculating on how useful adding an overload on one
particular operation might be.

That makes sense, and I think your description pretty much sums it up.
Maybe it can be transformed in a checklist:

1. Instance methods are preferred
2. Binary operators are implemented as static and instance methods, both
with offsets
3. Some instance methods have offset-related overloads, where it makes sense
4. Pure static methods are not welcome, except for some widespread
patterns, like factory methods (*)

* there are always exceptions of course

In my experience I rarely use static methods. Usually the need to use a
static method comes from:
* missing functionality, but in Kotlin it is typically implemented via
extensions
* binary operations: sometimes it's easier to read, and static functions
have cleaner semantics (function creates new object or modifies in-place?)
* factory methods
* serialization/deserialization functions, but this one is a tricky:
serialization usually requires member-access, but after some trial and
error I decided having private serialize delegate is better for API
consistency

But it's all my personal experience of course, when designing an API it's
probably better to do some analytics,
like count what's the most popular functions among the users (data
collected from top-100 java projects, for example).
Polls are fine too, but most of the time they're biased and do not
represent a large part of the community.


вт, 14 июн. 2022 г. в 14:07, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com>:

>
> On 14/06/2022 11:53, Alexander Biryukov wrote:
> > From my perspective the Java ecosystem has a "duality" in static and
> > instance methods. But probably this observation comes from Arrays and
> > many Apache *Utils libraries.
> > I think it's not really necessary to pick one, why shouldn't there be
> > 2 ways, at least for the functions which make sense to do so (binary
> > operators).
>
> This is true, we should not feel compelled to _have to pick one_. That
> said, especially in the case of `copy`, where directionality is
> important, a static method is, I think, a superior choice (in fact the
> instance version is called "copyFrom", to make the directionality pop
> out a bit more). But yes, we could still provide both (for binary
> methods), for convenience.
>
> The main point I wanted to make is that an offset parameter makes sense
> in _all_ the instance methods of memory segment (the unary operators).
> Because, if there's no offset argument in these methods (e.g. toArray)
> and you use your own offset system (like you do), the API becomes full
> of "sharp edges" where you can't just pass an offset and you have to
> slice instead.
>
> That's why I'm trying to uplevel the discussion a bit: if storing a
> MemorySegment and an associated long offset is a common enough operation
> in certain contexts, and we want to support that use case, then we need
> to pick a solution that's consistent about it, rather than speculating
> on how useful adding an overload on one particular operation might be.
> The latter is at severe risk of extrapolating from too few use cases,
> since this is a new API (the fact that we're having this discussion
> again after the one on copy is in itself a revealing fact).
>
> Maurizio
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20220614/72b0da84/attachment.htm>