On 15 February 2023 05:18:50 GMT, Rowan Tommins <[email protected]> wrote:
>My instinct was that it could just be a built-in class, with an internal pointer to a
>zend_string that's completely invisible to userland. Something like how the SimpleXML and DOM
>objects just point into a libxml parse result.
To make this a bit more concrete, what I was picturing was that instead of this example:
str_splice($this->pagemap[$pagepos][0], $x2, $size2, $data, $x, $size);
You would have something like this:
// Wrap an existing zend_string in an object
$destBuffer = Buffer:: fromString($this->pagemap[$pagepos][0]);
// Similar, but also track start and end offsets
$sourceBuffer = Buffer::fromSubString($data, $x, $size);
// Now do the actual memory copy
$destBuffer->splice($x2, $size2, $sourceBuffer);
The explicit size handling parameters of str_splice, and the str_realloc function, would be replaced
with methods to get and set the allocated length of a Buffer object. The buffer would only be shrunk
when requested, or when cast to string.
The $src_repeat argument feels somewhat out of place in a "splice" operation anyway, and
perhaps should be part of a different method.
On a different note, don't forget that we have named parameters now, which is a big help with
signatures like this; this example:
$vsize = str_splice($str, $pos, $pos2 - $pos + 1, $embed, 0, null, 1, false, $vsize);
Looks slightly less scary written like this:
$vsize = str_splice($str, $pos, $pos2 - $pos + 1, $embed, shrink: false, dst_lastsize: $vsize);
Regards,
--
Rowan Tommins
[IMSoP]