<div dir="ltr"><div>> 
That's why I'm trying to uplevel the discussion a bit: if storing a MemorySegment <br></div><div>> and an associated long offset is a common enough operation in certain contexts, <br></div><div>> and we want to support that use case, then we need to pick a solution that's consistent about it, <br></div><div>> rather than speculating on how useful adding an overload on one particular operation might be. </div><div><br></div><div>That makes sense, and I think your description pretty much sums it up.</div><div>Maybe it can be transformed in a checklist:</div><div><br></div><div>
1. Instance methods are preferred</div><div>2. Binary operators are implemented as static and instance methods, both with offsets<br></div><div>3. Some instance methods have offset-related overloads, where it makes sense<br></div><div>4. Pure static methods are not welcome, except for some widespread patterns, like factory methods (*)</div><div><br></div><div>* there are always exceptions of course<br></div><div><br></div><div>In my experience I rarely use static methods. Usually the need to use a static method comes from:</div><div>* missing functionality, but in Kotlin it is typically implemented via extensions</div><div>* binary operations: sometimes it's easier to read, and static functions have cleaner semantics (function creates new object or modifies in-place?)</div><div>* factory methods<br></div><div>* 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</div><div><br></div><div>But it's all my personal experience of course, when designing an API it's probably better to do some analytics,</div><div>like count what's the most popular functions among the users (data collected from top-100 java projects, for example).</div><div>Polls are fine too, but most of the time they're biased and do not represent a large part of the community.<br></div><div><div><br></div>

<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">вт, 14 июн. 2022 г. в 14:07, Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank">maurizio.cimadamore@oracle.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 14/06/2022 11:53, Alexander Biryukov wrote:<br>
> From my perspective the Java ecosystem has a "duality" in static and <br>
> instance methods. But probably this observation comes from Arrays and <br>
> many Apache *Utils libraries.<br>
> I think it's not really necessary to pick one, why shouldn't there be <br>
> 2 ways, at least for the functions which make sense to do so (binary <br>
> operators).<br>
<br>
This is true, we should not feel compelled to _have to pick one_. That <br>
said, especially in the case of `copy`, where directionality is <br>
important, a static method is, I think, a superior choice (in fact the <br>
instance version is called "copyFrom", to make the directionality pop <br>
out a bit more). But yes, we could still provide both (for binary <br>
methods), for convenience.<br>
<br>
The main point I wanted to make is that an offset parameter makes sense <br>
in _all_ the instance methods of memory segment (the unary operators). <br>
Because, if there's no offset argument in these methods (e.g. toArray) <br>
and you use your own offset system (like you do), the API becomes full <br>
of "sharp edges" where you can't just pass an offset and you have to <br>
slice instead.<br>
<br>
That's why I'm trying to uplevel the discussion a bit: if storing a <br>
MemorySegment and an associated long offset is a common enough operation <br>
in certain contexts, and we want to support that use case, then we need <br>
to pick a solution that's consistent about it, rather than speculating <br>
on how useful adding an overload on one particular operation might be. <br>
The latter is at severe risk of extrapolating from too few use cases, <br>
since this is a new API (the fact that we're having this discussion <br>
again after the one on copy is in itself a revealing fact).<br>
<br>
Maurizio<br>
<br>
<br>
</blockquote></div></div></div>