On Tue, Dec 7, 2021, at 3:42 AM, Hassan Ahmed wrote: > This is a great suggestion Hendra, I really believe that it may take > the new function to another level, but - with Larry's comment in mind > - this is a language design more than function design. Supporting the > list/array comprehensions will be a great step for PHP, as I can > remember that Nikita already implemented something like this > https://github.com/nikic/scalar_objects as a workaround but I am not > sure why does this was not implemented in the core yet. Almost all of > the array_* family functions - including array_column - can be > achieved by a `foreach` call. so I do not believe that we need to > decline the new function and maybe in the future, we can add more of > your suggestions for it. especially the `map` parameter which IMHO is > a promising addition, it can be a mixed argument [ string, array, > callable ]. BTW your thoughts led me to change the order of the > arguments for the new function to be `array_group($array, $index, > $columns)` I will update the RFC with this.
And if you want to map, reduce, or filter without grouping? Then you can't really use this function. And as noted, the order in which you apply those operations may matter, and no order is necessarily more obvious or beneficial. Either of these approaches would be superior to cramming more functionality into a single-purpose function to turn it into a single-function swiss army knife: https://wiki.php.net/rfc/comprehensions https://wiki.php.net/rfc/pipe-operator-v2 Swiss-army-knife functions are a design flaw. Robust primitives that compose nicely are superior in nearly every way. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
