<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 04/11/2025 15:23, Jorn Vernee wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:648a81d7-7848-4045-8a96-b4239bef7481@oracle.com">
      <blockquote type="cite" cite="mid:CAL4QsguYkBshtgiD4v2MsnirbOsm+Lbaw6KSAc7pryopN6=z+w@mail.gmail.com">
        <div dir="ltr">
          <div class="gmail_quote gmail_quote_container">
            <div>Do you have thoughts on the best way to proceed here?
              Do you think it makes sense to do incrementally, or would
              you prefer to see all of these related changes happen
              together under a single issue?<br>
              <br>
            </div>
          </div>
        </div>
      </blockquote>
      <p>I don't have a preference. Since you've already started a PR
        for enhancing getString, maybe you can focus on that for now,
        and we'll file followup issues for the others. Splitting things
        up might be nice since there's probably some benchmarking work
        involved for each. I think the copy and allocateFrom overload
        can be done in one patch though.</p>
    </blockquote>
    <p>I think I sort of do have a preference :-)</p>
    <p>My feeling is that we're dealing with 2-3 different APIs that are
      all tightly interconnected. We have some ideas on how to solve
      some (I think getString with explicit length seems the most
      settled), but we're still playing with other ideas for the others
      (like copy, or memory segment views). And we also have to think
      about relationship with SegmentAllocator.</p>
    <p>For this reason, I'd prefer to think about it more holistically
      and think about all the related APIs at once.</p>
    <p>Once we get a consensus on how to proceed we can decide whether
      to pursue them all in a single PR, or split them into separate
      PRs.</p>
    <p>But it would be unfortunate, I think, if the first PR would later
      reveal to be a dead end for the other use cases.</p>
    <p>I plan to think about this some more (but I need some more time).</p>
    <p>Cheers<br>
      Maurizio<br>
    </p>
  </body>
</html>