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