On Mon, Oct 21, 2024 at 3:24 PM Larry Garfield <la...@garfieldtech.com> 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
