Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123858
Content-Type: text/plain;
	charset=us-ascii
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
In-Reply-To: <0DE5ACCD-C321-4872-ADDA-B7F716FC41B0@woofle.net>
Date: Wed, 26 Jun 2024 02:10:30 -0400
Cc: "Gina P. Banyard" <internals@gpb.moe>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <E261DDEA-C496-483C-AC22-6D65A41EC215@newclarity.net>
References: <bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@gpb.moe>
 <E146A171-CFA6-4E3F-91AA-2ACE7710A6D9@newclarity.net>
 <dbGe34EpQtjyP7ja7aUHnZYwmtupxeLd7EoOv3JjQMSh_UqoMrbqo5PkxrlIiaXJePC1-TfLyyblz5QDM13OkitgBqKPuSvh28WiJFh7qJI=@gpb.moe>
 <B958318C-B61D-4618-BA7D-3BF204C5B3CD@newclarity.net>
 <0DE5ACCD-C321-4872-ADDA-B7F716FC41B0@woofle.net>
To: Dusk <dusk@woofle.net>
From: mike@newclarity.net (Mike Schinkel)

> On Jun 26, 2024, at 1:39 AM, Dusk <dusk@woofle.net> wrote:
>=20
> On Jun 25, 2024, at 22:18, Mike Schinkel <mike@newclarity.net> wrote:
>> This leads me to think `strtok()` should not be deprecated given how =
inefficient string handling in PHP can otherwise be, at least not =
without a much more efficient object for string parsing.
>=20
> What would be really useful as a replacement for strtok() - among =
other things - would be a function analogous to MySQL's =
SUBSTRING_INDEX():
>=20
> =
https://dev.mysql.com/doc/refman/8.4/en/string-functions.html#function_sub=
string-index
>=20
> Where SUBSTRING_INDEX($a, $b, $c) is functionally equivalent to =
explode($a, $b)[$c], but with the added ability to use negative indices =
to count from the end of the input.

Yes. There are numerous quality-of-life functions like that which would =
improve PHP DX, performance, and likely security if incorporated into =
the standard library.=20

Unfortunately there is a generally antipathy on this list towards adding =
functions that "can be written in userland" even though relegating them =
to userland means many people writing, writing about and publishing many =
different named functions doing similar and often incompatible things, =
and doing them less efficiently than if the one-time bullet was bitten =
and they were written in C, added to the docs, and included in core PHP.=20=


#fwiw

-Mike

P.S. And no, `SUBSTRING_INDEX($a, $b, $c)` would not add a significant =
maintenance burden. Simple functions are an order of magnitude easier to =
maintain than, for example, adding new syntax for new language features, =
or adding a library feature needs to be upgraded in response to an =
evolution orthogonal to PHP, such as supporting a file format, a =
protocol or database connector.=