On 15.02.2023 at 06:18, Rowan Tommins wrote: > On 15 February 2023 02:35:42 GMT, Thomas Hruska <thru...@cubiclesoft.com> > wrote: > >> On 2/14/2023 2:02 PM, Rowan Tommins wrote: >> >> I thought about that but didn't know how well it would be received nor, >> perhaps more importantly, the direction it should take (i.e. a formal Zend >> type in the engine, extending the existing zend_string type, a class, some >> combination, or something else entirely). All of the more advanced options >> I came up with would have required some code changes to the PHP source >> itself with a new data type being the most involved and probably the most >> controversial. > > 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. > > Then to add to existing functions requires changing an argument type from > string to string|Buffer, rather than adding new arguments. > > No change to the type system needed, internally or externally, just some code > to unwrap the pointer. But perhaps I'm being naive and oversimplifying, as I > don't have a deep understanding of the engine. > >> I'm not entirely sure what the next step here should be. Should I go >> research the above, or go back and develop/test and then propose something >> concrete in an OO direction and gather feedback at that point, or should we >> hash it out a bit more here on the list to get a more specific direction to >> go in? > > Well, those were just my thoughts; maybe someone else will come along shortly > with a very different take.
I'm very late on this discussion, but I think it is an interesting topic, and maybe <https://github.com/cmb69/php-stringbuilder>, which I had written long ago just to check some assumptions, can serve as POC. It is certainly possible to have such a string buffer class without having to patch the engine; it could even be made available as PECL extension (first). Note that this StringBuilder uses `smart_str`s[1] what might be a good idea or not. But certainly you could use some other internal handling; interoperability with `zend_string`s[2] requires to copy the char arrays in most cases anyway, since these have a fixed length, and if these copies are reduced to a minimum (i.e. the new class has enough flexibility to work without casting to and from string), that should be bearable. Not sure if that would work for the "gd imageexportpixels() and imageimportpixels()" RFC[3], but it might be worth investigating. [1] <https://www.phpinternalsbook.com/php7/internal_types/strings/smart_str.html> [2] <https://www.phpinternalsbook.com/php7/internal_types/strings/zend_strings.html> [3] <https://wiki.php.net/rfc/gd_image_export_import_pixels> Cheers, Christoph
