On Wed, Jul 17, 2024, at 9:01 AM, Bilge wrote:
On 17/07/2024 01:41, Levi Morrison wrote:
Adding arguments to a function can mess up internal callbacks, btw, so I don't like modifying the
existing function.
Which internal callbacks can be messed up by this change? They clearly
aren't tested, as the build is passing.
Cheers,
Bilge
There's a number of issues here.
PHP-defined functions ignore excess arguments.
C-defined functions error on excess arguments.
A function with an optional second argument... may break if it gets passed an optional argument that isn't aligned with its expectation. intval() is the usual example (PHP: intval - Manual), but it would also impact something like trim(). If someone is using a function with one param and one optional param as a callback right now, suddenly passing the key as the second argument could cause all sorts of weirdness.
Similarly, if someone is using a single-param C-defined function as a callback right now, and array_reduce() starts passing a second argument, it will fatal.
I ran into this issue while building Crell/fp, and my only solution (after swearing a lot) was to just make two separate versions of every operation: One that passes the key and one that doesn't. (cf: fp/src/array.php at master · Crell/fp · GitHub) The user has to pick the right one. That is, sadly, the only reliable solution, even if done in the stdlib.
(Of course, the real solution is to introduce a separate map/dict type that has its own dedicated API for map/filter/reduce, but now we're well out of scope... Using the same structure for lists and maps is PHP's original sin.)
--Larry Garfield