Re: [RFC] Deprecations for PHP 8.4

From: 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 [email protected] to get a copy of this message


> On Jun 27, 2024, at 11:26 AM, Tim Düsterhus <[email protected]> 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):
> 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


Thread (68 messages)

« previous php.internals (#123964) next »