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

Reply via email to