Re: [RFC] Working With Substrings
| From: | Christoph M. Becker | Date: | Sat, 27 Jul 2024 13:26:09 +0000 |
| Subject: | Re: [RFC] Working With Substrings | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-124650@lists.php.net to get a copy of this message | ||
On 15.02.2023 at 06:18, Rowan Tommins wrote:
> On 15 February 2023 02:35:42 GMT, Thomas Hruska <thruska@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_strs[1] what might be a good
idea or not. But certainly you could use some other internal handling;
interoperability with zend_strings[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