Additional mismatch overloads for memory segments

Jorn Vernee jorn.vernee at oracle.com
Wed Jun 15 13:46:07 UTC 2022


Just wanted to mention that it's not just offsets, but also lengths in 
some cases.

For instance, fill might need a length and offset overload. And I've 
also felt in the past that getUtf8String, which currently only takes an 
offset, should be split into 2 overloads, one that takes an offset and 
length, and one that takes no arguments (which would internally look for 
a null terminator).

Jorn

On 14/06/2022 14:40, Maurizio Cimadamore wrote:
>
> On 14/06/2022 13:03, Alexander Biryukov wrote:
>> 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 (*)
>
> I would split (3) as follows:
>
> 3a. Instance methods have an additional offset parameter
> 3b. Where it makes sense, offset-free overloads might be provided 
> (e.g. call method in (3a) with offset=0)
>
> This feels more principled, as (3a) is a primitive and (3b) is sugare 
> than can easily be derived from that.
>
> Re. your point of using analytics, again, this is a relatively new 
> API, there's not much code using it out there, so the risk of 
> "overfitting" is real.
>
> I'm slightly on the fence w.r.t. having both static and instance 
> variants for binary methods - that said, as long as we can clearly 
> explain what's the primitive (the static method), I think the API can 
> still be explain in a relatively straightforward fashion.
>
> Maurizio
>
>
>


More information about the panama-dev mailing list