Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126355
Message-ID: <88486267-f5e5-485b-bce1-e30163b5e703@bastelstu.be>
Date: Sat, 8 Feb 2025 19:46:12 +0100
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] Introduction - Sam Lewis
To: Sam Lewis <sam.lewis0602@gmail.com>, Rob Landers <rob@bottled.codes>
Cc: internals@lists.php.net
References: <CAD91n9L6B7fe1wtqqeOH+6PT1so-+TxB3uOEuVDL7W5T+U27Lw@mail.gmail.com>
 <8053193b-0637-4db4-825d-56e7746111dd@bastelstu.be>
 <e0ef2efc-2933-451a-9259-b6c9d5491bdf@app.fastmail.com>
 <CAD91n9KpV+G8WpJAcjmUb_yYnzXf6Ev7NE-w=8or5Uh-7GWZ8Q@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAD91n9KpV+G8WpJAcjmUb_yYnzXf6Ev7NE-w=8or5Uh-7GWZ8Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi Sam

Please do not "top-post" on this mailing list. This means: Please put 
your reply below the quoted part and ideally also cut the quoted part to 
the minimum context that you actually want to reply to. You can see how 
I did this in my first reply to you and also in this reply.

On 2/8/25 18:16, Sam Lewis wrote:
> That's fair, maybe that will increase the value proposition of the RFC
> enough to be worth considering more seriously.

A well-designed “Units extension” would certainly be more valuable that 
adding a few functions without a clear plan / proper API design. But it 
would probably still be something that would better be solved in 
userland as a composer library. Unit conversions functions will likely 
not experience a relevant performance improvement when implemented 
natively, they are not particularly hard to implement with regard to 
edge cases so that they would warrant a “well-tested” and “blessed” core 
implementation and they are unlikely to be so commonly used that they 
need to *always* be available. Having them in a userland API would also 
allow them to move more quickly: New units could be added on-demand, 
rather than being restricted to a once-per-year release cycle.

The type of functionality that is nowadays added to PHP’s standard 
library is “building block” functionality: Functions that a userland 
developer would commonly need in their custom library or application.

The `array_find` functions added in PHP 8.4 are a good example. It's 
something that every major framework already implements in one way or 
another, it fits with the existing `array_filter` functionality and it's 
so generically useful that many libraries benefit from it.

The same is true for `Randomizer::getBytesFromString()` added in PHP 
8.3. It's also commonly implemented and as it turns out, it is very 
susceptible to being incorrectly implemented (due to off-by-one errors). 
For that there's also the existing Randomizer class which a clear API 
design and scope so that the function fits in nicely with the existing API.

Best regards
Tim Düsterhus