Re: [RFC] Change behaviour of array sort functions to return a copy of the sorted array
On Mon, Oct 21, 2024 at 3:24 PM Larry Garfield <[email protected]>
wrote:
> I am confused by this statement. How is "adding more functions that do
> exactly what they say on the tin and act in a predictable fashion" bad?
> It's not like we're running out of space for functions. Small,
> purpose-built, highly-predictable APIs that fully address a problem space
> are the ideal goal; the number of them is largely irrelevant.
>
> I wouldn't mind array_sorted() instead of sorted(), since it wouldn't work
> on iterables. But array_sort() vs sort() is just horribly confusing for no
> good reason, and the API itself does nothing to tell you which is which.
>
> --Larry Garfield
>
Couldn't it be said that prefixing native array functions with "array_" and
not adding "ed" to the middle (e.g. array_walked_recursive) or end of
native functions is moving toward naming convention normalcy?
Does PHP have any "ed" functions?
Having separate array_*() and *() functions offers a path to the possible
future decision to cull the *() functions and/or remove the
modify-by-reference behaviour of array_*() functions ...if that is ever
desirable.
I see this naming distinction as a stepping stone to a more consistent
naming convention rather than the final solution.
(Just like defining the function alias preg_escape() as a pathway to
removing preg_quote() -- which is a function that doesn't do what it says
on the tin.)
Mick
Thread (24 messages)