Re: [RFC] Deprecations for PHP 8.4

> On Jun 26, 2024, at 1:39 AM, Dusk <dusk@woofle.net> wrote: > > 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. > > What would be really useful as a replacement for strtok() - among other things - would be a > function analogous to MySQL's SUBSTRING_INDEX(): > > > https://dev.mysql.com/doc/refman/8.4/en/string-functions.html#function_substring-index > > > 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. 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. #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.