Re: [RFC] Deprecations for PHP 8.4
| From: | Chuck Adams | Date: | Thu, 27 Jun 2024 20:57:25 +0000 |
| Subject: | Re: [RFC] Deprecations for PHP 8.4 | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-123964@lists.php.net to get a copy of this message | ||
> On Jun 27, 2024, at 11:26 AM, Tim Düsterhus <tim@bastelstu.be> wrote:
>
> Hi
>
> On 6/27/24 19:09, Chuck Adams wrote:
>> Personally I say let strtok be and just admit in the documentation that it’s weird
>> because C.
>
> strtok() is not weird because C. It does not rely on the libc strtok()
> function and did not since at least 1999 (and likely never did):
> E v
> M5߃https://github.com/php/php-src/commit/257de2baded9330ff392f33fd5a7cc0ba271e18d#diff-fcf8a2a38ee4a0e3e2cb7c47251c9920ba8c5886d85969f676f9ddbee7aba503R332
Okay, how about “weird because POSIX”? The API gets the blame then, not any implementation.
> strtok() is weird, because someone believed that relying on global state
> was good API design. I find that excusable, because it happened more
> than a quarter of a century ago.
Oh I think strtok is awful, but it also looks like it beats the pants off the alternatives
performance-wise. I imagine it’s also completely ignorant about unicode, so yeah…
I guess it should at least be deprecated until being replaced by a userspace version with similar
performance.
—c