On 15 February 2023 05:18:50 GMT, Rowan Tommins <rowan.coll...@gmail.com> 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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
