Re: [RFC] Change behaviour of array sort functions to return a copy of the sorted array

On Sun, Oct 20, 2024, at 4:39 PM, Bob Weinand wrote: > On 20.10.2024 23:23:21, Ilija Tovilo wrote: >> Hi Bilge >> >> On Sun, Oct 20, 2024 at 10:30 PM Bilge <bilge@scriptfusion.com> wrote: >>> I fail to see the logic of present tense = mutate, past tense = copy. At least there is >>> a pattern to it, but I would have to look it up several times before it sunk in since it is not >>> intuitive at all. >> It's sorted, the adjective. As in, "give me a _sorted_ array", >> compared to "_sort_ this array". It's a common convention and I always >> found it intuitive. >> >> Ilija > > Hey Ilija, > > yes, I agree it's intuitive. > > However, I consider it bad to add extra functions for this behaviour. > There's very little gain in extra functions, sort(), sorted(), > shuffle(), shuffled(), etc.. > > So yeah, I'd agree on the naming *if* these were the only variation of > sorting/shuffling etc. functions. But that's not the case here. > > > I, for my part, very much like the RFC, for that it gives functionality, > which I've been missing quite some times already and is minimally invasive. > > Bob 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