On Mon, Oct 21, 2024 at 10:19 AM Bilge <bi...@scriptfusion.com> wrote:
> On 21/10/2024 00:16, mickmackusa wrote: > > Might the transition be simpler if the naming convention is standardized > to have array_ meaning "returns the input [sorted|shuffled|traversed] > array" and without the prefix means "modify by reference"? > > That naming convention will not look absurd among other native array_ > functions and prefix-trimmed functions will afford developers to continue > using the original modify by reference behavior (if they have performance > or memory reasons). > > | returns copy of array | by reference | > | ---------------------- |---------------- | > | array_sort() | sort() | > | array_rsort() | rsort() | > | array_asort() | asort() | > | array_arsort() | arsort() | > | array_ksort() | ksort() | > | array_krsort() | krsort() | > | array_natsort() | natsort() | > | array_natcasesort() | natcasesort() | > | array_usort() | usort() | > | array_uasort() | uasort() | > | array_uksort() | uksort() | > | array_multisort() | multisort() | > | array_shuffle() | shuffle() | > | array_walk() | walk() | > | array_walk_recursive() | walk_recursive() | > > Good luck regardless, > mickmackusa > > I like this in theory, but array_multisort() and array_walk*() already > broke your proposed convention :( > > Cheers, > Bilge > Yes, the RFC was already intending to break backward compatibility to a small degree. I am suggesting that multisort(), walk(), and walk_recursive() be defined in the language so that users disrupted by this change can do a simple search-replace in their applications. This way, all of the array_*() functions can be defined or altered to return a copy. I acknowledge the high likelihood that existing projects may already have helper functions like walk(), walk_recursive(), and multisort(), but this again is resolved by a simple search-replace. I do not know if there is any appetite to have the array_*() functions NOT modify by reference at all. That would be a much larger break. Maybe that could be a future consideration set up by this distinction in naming convention. Having array_walk*() return an array would mark a significant change in my functional iteration decision making. Because array_walk*() functions allow key access (and have the $arg third parameter), there will be places where I can enjoy array_walk() instead of passing an array of keys to array_map() or array_reduce() and return the modified array. I don't mean to push super hard for such changes, I just want to expand on available strategies so that relevant pathways can be discussed. p.s. Too distant from the concern of this RFC is my wish that array_walk($array, ksort(...)) and many other similar scenarios "worked". https://stackoverflow.com/q/11399741/2943403 (sorry for double email you Bilge, I failed to reply-all) Mick
