Re: [PHP-DEV] RFC [Discussion] array_column results grouping

  116571
December 5, 2021 14:02 rowan.collins@gmail.com (Rowan Tommins)
On 05/12/2021 10:41, Mark Randall wrote:
> On 04/12/2021 14:21, Marco Pivetta wrote: >> Gonna vote `no` on this: please design new/dedicated functions, >> rather than >> expanding optional parameters. > > > I would vote no for the same reason.
Since this is explicitly an open question in the current RFC draft, it seems a bit premature to talk about voting, rather than encouraging the RFC to develop in a particular direction. For what it's worth, I agree that a new function is probably better here, because the argument list of array_column is already quite complicated. A new function also leaves the way open to add more functionality, such as the "reducer" callback suggested by Hendra Gunawan; I don't think that's needed in the first implementation, though. In general, I like the proposal - like array_column itself, it's one of those things that's fairly _simple_ to do in userland, but also fairly _often_ done, so compacting it to a neat function call seems useful. Regards, -- Rowan Tommins [IMSoP]
  116572
December 6, 2021 08:44 7snovic@gmail.com (Hassan Ahmed)
Hello Folks, Thanks a lot for your feedback, as already mentioned in
the RFC and as mentioned by Rowan too a new function is an option. I
think that mostly we will go with the new function option.
I will try to edit the PR to add a new function, does there any
suggestions/naming conventions for the new function? a colleague
suggested being `array_group_by` and Hendra already suggested to be
`array_column_group` which is good too.

Regards,
Hassan

On Sun, Dec 5, 2021 at 4:02 PM Rowan Tommins collins@gmail.com> wrote:
> > On 05/12/2021 10:41, Mark Randall wrote: > > On 04/12/2021 14:21, Marco Pivetta wrote: > >> Gonna vote `no` on this: please design new/dedicated functions, > >> rather than > >> expanding optional parameters. > > > > > > I would vote no for the same reason. > > > Since this is explicitly an open question in the current RFC draft, it > seems a bit premature to talk about voting, rather than encouraging the > RFC to develop in a particular direction. > > For what it's worth, I agree that a new function is probably better > here, because the argument list of array_column is already quite > complicated. A new function also leaves the way open to add more > functionality, such as the "reducer" callback suggested by Hendra > Gunawan; I don't think that's needed in the first implementation, though. > > In general, I like the proposal - like array_column itself, it's one of > those things that's fairly _simple_ to do in userland, but also fairly > _often_ done, so compacting it to a neat function call seems useful. > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php >
  116575
December 6, 2021 10:23 claude.pache@gmail.com (Claude Pache)
> Le 6 déc. 2021 à 09:44, Hassan Ahmed <7snovic@gmail.com> a écrit : > > Hello Folks, Thanks a lot for your feedback, as already mentioned in > the RFC and as mentioned by Rowan too a new function is an option. I > think that mostly we will go with the new function option. > I will try to edit the PR to add a new function, does there any > suggestions/naming conventions for the new function? a colleague > suggested being `array_group_by` and Hendra already suggested to be > `array_column_group` which is good too. > > Regards, > Hassan >
Now that we have named arguments, the issue of long and complicated list of arguments is considerably weaken, since you can write: array_column($foo, column_key: 'name', grouping: true); in lieu of: array_column($foo, null, 'name', true) Also, an alternative to a new function, is reusing the same function with an alternative signature, as it was done for setcookie: https://www.php.net/manual/fr/function.setcookie.php <https://www.php.net/manual/fr/function.setcookie.php> I have no opinion about which of the three approaches (new parameter, same function with alternative signature, new function) is better; I just mention the various alternatives. —Claude
  116577
December 6, 2021 19:37 7snovic@gmail.com (Hassan Ahmed)
The named arguments are a great thing to set in mind, but I think that
we will go to complicate it with optional arguments.
there is a comment on the PR that asks for another option to preserve
the sub-array index to be the new array index. also with the comments
by `Hendra Gunawan` in mind. adding a new optional argument will make
it harder to expand it in the future.

Hassan Ahmed

On Mon, Dec 6, 2021 at 12:24 PM Claude Pache pache@gmail.com> wrote:
> > > > Le 6 déc. 2021 à 09:44, Hassan Ahmed <7snovic@gmail.com> a écrit : > > Hello Folks, Thanks a lot for your feedback, as already mentioned in > the RFC and as mentioned by Rowan too a new function is an option. I > think that mostly we will go with the new function option. > I will try to edit the PR to add a new function, does there any > suggestions/naming conventions for the new function? a colleague > suggested being `array_group_by` and Hendra already suggested to be > `array_column_group` which is good too. > > Regards, > Hassan > > > > Now that we have named arguments, the issue of long and complicated list of arguments is considerably weaken, since you can write: > > array_column($foo, column_key: 'name', grouping: true); > > in lieu of: > > array_column($foo, null, 'name', true) > > Also, an alternative to a new function, is reusing the same function with an alternative signature, as it was done for setcookie: > > https://www.php.net/manual/fr/function.setcookie.php > > I have no opinion about which of the three approaches (new parameter, same function with alternative signature, new function) is better; I just mention the various alternatives. > > —Claude
  116578
December 6, 2021 22:16 the.liquid.metal@gmail.com (Hendra Gunawan)
> > Hello Folks, Thanks a lot for your feedback, as already mentioned in > the RFC and as mentioned by Rowan too a new function is an option. I > think that mostly we will go with the new function option. > I will try to edit the PR to add a new function, does there any > suggestions/naming conventions for the new function? a colleague > suggested being `array_group_by` and Hendra already suggested to be > `array_column_group` which is good too.
It would be better if You add another voting item for this one. In my opinion, `column` is less important to be included, and `array_group` is sufficiently descriptive. `reducer` is one of the candidates to be included. Additionally, there are `mapper`, `filter`, and `sorter`. So Obviously we need a new function, rather than modify the old one. To be clear and to make it simpler, all callbacks operate on the deepest subgroup. Signature: reducer(array|object $item, int|string $index, mixed $cumulative): mixed mapper(array|object $item): array|object filter(array|object $item, int|string $index): bool sorter(array|object $item1, array|object $item2): int A note in case you are able to implement them: - `reducer` and `mapper` cannot coexist in a single function call. - `filter` should be executed before `reducer` or `mapper`. - `sorter` should be decided whether it executes before or after `reducer`/ `mapper`: `sorter` is more suitable to execute before `filter`, but more suitable after `mapper`. A note for consumers: - `mapper` is designed to operate on the subgroup item, but it can be operated on the field value of the item. - filtering can be done inside `reducer` or `mapper`, but the number of subgroup members is as it is. With dedicated `filter` supplied, we can decrease the number. - If You want to filter an intermediate group, You can use `unset` or `if-else` $group = array_group($people, ["education", "sex"], FN_REDUCER); foreach ($group as &$eduGroup) { foreach ($eduGroup as &$sexGroup) { unset($sexGroup["male"]); } } Not a perfect solution, but at least your code is reduced. Best Regards Hendra Gunawan.
  116579
December 7, 2021 00:59 larry@garfieldtech.com ("Larry Garfield")
On Mon, Dec 6, 2021, at 4:16 PM, Hendra Gunawan wrote:
>> >> Hello Folks, Thanks a lot for your feedback, as already mentioned in >> the RFC and as mentioned by Rowan too a new function is an option. I >> think that mostly we will go with the new function option. >> I will try to edit the PR to add a new function, does there any >> suggestions/naming conventions for the new function? a colleague >> suggested being `array_group_by` and Hendra already suggested to be >> `array_column_group` which is good too. > > It would be better if You add another voting item for this one. In my opinion, > `column` is less important to be included, and `array_group` is sufficiently > descriptive. > > `reducer` is one of the candidates to be included. Additionally, there are > `mapper`, `filter`, and `sorter`. So Obviously we need a new function, rather > than modify the old one. > > To be clear and to make it simpler, all callbacks operate on the deepest > subgroup. > > Signature: > > reducer(array|object $item, int|string $index, mixed $cumulative): mixed > mapper(array|object $item): array|object > filter(array|object $item, int|string $index): bool > sorter(array|object $item1, array|object $item2): int > > A note in case you are able to implement them: > - `reducer` and `mapper` cannot coexist in a single function call. > - `filter` should be executed before `reducer` or `mapper`. > - `sorter` should be decided whether it executes before or after `reducer`/ > `mapper`: `sorter` is more suitable to execute before `filter`, but more > suitable after `mapper`. > > A note for consumers: > - `mapper` is designed to operate on the subgroup item, but it can be operated > on the field value of the item. > - filtering can be done inside `reducer` or `mapper`, but the number of > subgroup members is as it is. With dedicated `filter` supplied, we can > decrease the number. > - If You want to filter an intermediate group, You can use `unset` or `if-else` > > > $group = array_group($people, ["education", "sex"], FN_REDUCER); > foreach ($group as &$eduGroup) { > foreach ($eduGroup as &$sexGroup) { > unset($sexGroup["male"]); > } > } > > Not a perfect solution, but at least your code is reduced.
Better map/filter/reduce primitives in PHP would be dandy, but they have nothing to do with array grouping. They're a separate operation that should be composed with grouping. Packing them all into a single function sounds like a terrible idea. If we wanted that... that's called list comprehensions, which I *would* support and even tried to rally support for a few years ago, but got met with a big shrug. :-) --Larry Garfield
  116580
December 7, 2021 01:43 the.liquid.metal@gmail.com (Hendra Gunawan)
Revision to my recommendation are:

1. signature:

    array_group(
        array|object $array,
        int|string|array $index_key,
        callable $reducer = null,
        callable $mapper = null,
        callable $filter = null,
        callable $sorter = null,
    ): array

2. `sorter` should be executed before `filter`, because as far as I can think,
   there is no way to do this by yourself. So the sequence should be:
   `sorter` > `filter` > `mapper`|`reducer`

> > Better map/filter/reduce primitives in PHP would be dandy, but they have > nothing to do with array grouping. They're a separate operation that should > be composed with grouping. Packing them all into a single function sounds > like a terrible idea. > > If we wanted that... that's called list comprehensions, which I would > support and even tried to rally support for a few years ago, but got met > with a big shrug. :-)
Suppose that my boss order me to provide statistical data of students. He wants a brief data companied with zoom button on each row. This buttons displays all fields in which brief data has, plus another zoom button on it's own row. And so on to some level. Additionally He wants the data not just by area division, but also by gender as a whole. // These are reducer $fnAvg = fn() => {/*...*/} $fnQ1 = fn() => {/*...*/} $fnQ2 = fn() => {/*...*/} $fnQ3 = fn() => {/*...*/} $fnLowest = fn() => {/*...*/} $fnHighest = fn() => {/*...*/} $dAvg = array_group($data, "district", $fnAvg); $dQ1 = array_group($data, "district", $fnQ1); $dQ2 = array_group($data, "district", $fnQ2); // ... and 3 others $wAvg = array_group($data, ["district", "ward"], $fnAvg); $wQ1 = array_group($data, ["district", "ward"], $fnQ1); $wQ2 = array_group($data, ["district", "ward"], $fnQ2); // ... and 3 others $cAvg = array_group($data, ["district", "ward", "cluster"], $fnAvg); $cQ1 = array_group($data, ["district", "ward", "cluster"], $fnQ1); $cQ2 = array_group($data, ["district", "ward", "cluster"], $fnQ2); // ... and 3 others $sAvg = array_group($data, "sex", $fnAvg); $sQ1 = array_group($data, "sex", $fnQ1); $sQ2 = array_group($data, "sex", $fnQ2); // ... and 3 others output: $dAvg = [ "district1" => 123, "district2" => 234, ... ]; $dQ1 = [ "district1" => 123, "district2" => 234, ... ]; ... $wAvg = [ "district1" => [ "ward1" => 123, "ward2" => 234, ], "district2" => [ "ward3" => 123, "ward4" => 234, ], ... ]; $wQ1 = [ "district1" => [ "ward1" => 123, "ward2" => 234, ], "district2" => [ "ward3" => 123, "ward4" => 234, ], ... ]; ... $sAvg = [ "female" => 123, "male" => 234, ... ]; $sQ1 = [ "female" => 123, "male" => 234, ... ]; `array_group` is just a simple handy tool which can manipulate a bunch of data without touching SQL, DQL, query builder, or any producer anymore just to align the output to the need. Best Regards Hendra Gunawan.
  116581
December 7, 2021 03:01 the.liquid.metal@gmail.com (Hendra Gunawan)
> > Better map/filter/reduce primitives in PHP would be dandy, but they have > nothing to do with array grouping. They're a separate operation that should > be composed with grouping. Packing them all into a single function sounds > like a terrible idea. > > If we wanted that... that's called list comprehensions, which I would > support and even tried to rally support for a few years ago, but got met > with a big shrug. :-)
`array_group` is just a simple handy tool which can manipulate a bunch of data without touching SQL, DQL, query builder, or any producer anymore just to align the output to the need. Of course we can code with whatever programming paradigm or style we want, especially if the algorithm is much more complex. Here, i offer you the very basic functionality and without external library. So my coworker does not have to dig into that library, or ask me. The original proposal is to offer grouping, and may be to avoid `foreach`. I think if the only purpose is to group an array, it is halfly baked function- ality. Previously, I had shown you that `foreach` is not too bad to use. Otherwise, I will suggest to the author don't bother with new function, you're wasting your time. With that original proposed functionality, We have to use an additional `foreach` or function call even though it is a basic operation. Moreover, the original purpose is preserved, if we do not give any optional params.
  116583
December 7, 2021 09:42 7snovic@gmail.com (Hassan Ahmed)
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.

~Hassan Ahmed.

On Tue, Dec 7, 2021 at 5:01 AM Hendra Gunawan
metal@gmail.com> wrote:
> > > > > Better map/filter/reduce primitives in PHP would be dandy, but they have > > nothing to do with array grouping. They're a separate operation that should > > be composed with grouping. Packing them all into a single function sounds > > like a terrible idea. > > > > If we wanted that... that's called list comprehensions, which I would > > support and even tried to rally support for a few years ago, but got met > > with a big shrug. :-) > > `array_group` is just a simple handy tool which can manipulate a bunch of data > without touching SQL, DQL, query builder, or any producer anymore just to align > the output to the need. > > Of course we can code with whatever programming paradigm or style we want, > especially if the algorithm is much more complex. Here, i offer you the very > basic functionality and without external library. So my coworker does not have > to dig into that library, or ask me. > > The original proposal is to offer grouping, and may be to avoid `foreach`. > I think if the only purpose is to group an array, it is halfly baked function- > ality. Previously, I had shown you that `foreach` is not too bad to use. > Otherwise, I will suggest to the author don't bother with new function, you're > wasting your time. With that original proposed functionality, We have to use an > additional `foreach` or function call even though it is a basic operation. > Moreover, the original purpose is preserved, if we do not give any optional > params. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php >
  116584
December 7, 2021 17:33 larry@garfieldtech.com ("Larry Garfield")
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
  116585
December 7, 2021 23:26 the.liquid.metal@gmail.com (Hendra Gunawan)
> > 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
You can modify it slightly if you eager to: array_group( ... null|int|string|array $index_key, ... ): array If You provide `null`, it will operate on a bare array, no grouping involved. As a consequence, users have to provide `reducer` or `mapper`. So virtually, You design `array_group` to swallow `array_reduce` and `array_map`. Though, `array_map` is actually a different API compared to `array_reduce` or `array_group`. Interestingly, you will get a better quality of code if you include `reducer: ` and `mapper: ` consistently, whatever array level you work with. // `array_reduce` and `array_map` alternative array_group($array, null, reducer: $fnReducer); array_group($array, null, mapper: $fnMapper); array_group($array, "level1", reducer: $fnReducer); array_group($array, "level1", mapper: $fnMapper); array_group($array, ["level1", "level2"], reducer: $fnReducer); array_group($array, ["level1", "level2"], mapper: $fnMapper); I hope there is no bias between the proposed name (`array_group`) and its functionality.
> > 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:
Not a swiss army knife, just a penknife. AS i wrote before, it is just a shortcut. If you really mind about that, we can cancel `filter` and `sorter`, leaving only `reducer` and `mapper`. Thought, we can filtering and sorting before `array_group`, but i don't know whether it is as accurate as embedding them into `array_group` or not. If not, we have to iterate manually, do filtering and/or sorting, then reducing/mapping. Of course these are wonderful proposals. Yes, they are superior. To be honest, I really hope they are landed in PHP. I already imagine what part of my code will be replaced by them. Since I am not a C coder and totally blind about the engine, I don't have my own opinion whether we lost good things or not, by not adding them to PHP.
  116586
December 8, 2021 09:35 7snovic@gmail.com (Hassan Ahmed)
Hendra Gunawan IMHO your suggestions is not related to
`array_group()`, you are talking about a great change in PHP as
mentioned by Larry, since we can have `Array($input, group(),
reducer(), mapper(), filter() ..... and so forth);` or even any other
way to handle the list comprehensions. but for array_group I think
that we should keep it to the minimal, to only group array.

~Hassan Ahmed

On Wed, Dec 8, 2021 at 1:26 AM Hendra Gunawan
metal@gmail.com> wrote:
> > > > > 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 > > You can modify it slightly if you eager to: > > array_group( > ... > null|int|string|array $index_key, > ... > ): array > > If You provide `null`, it will operate on a bare array, no grouping involved. > As a consequence, users have to provide `reducer` or `mapper`. So virtually, > You design `array_group` to swallow `array_reduce` and `array_map`. Though, > `array_map` is actually a different API compared to `array_reduce` or > `array_group`. > > Interestingly, you will get a better quality of code if you include `reducer: ` > and `mapper: ` consistently, whatever array level you work with. > > // `array_reduce` and `array_map` alternative > array_group($array, null, reducer: $fnReducer); > array_group($array, null, mapper: $fnMapper); > > array_group($array, "level1", reducer: $fnReducer); > array_group($array, "level1", mapper: $fnMapper); > array_group($array, ["level1", "level2"], reducer: $fnReducer); > array_group($array, ["level1", "level2"], mapper: $fnMapper); > > I hope there is no bias between the proposed name (`array_group`) and its > functionality. > > > > > 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: > > Not a swiss army knife, just a penknife. AS i wrote before, it is just a > shortcut. If you really mind about that, we can cancel `filter` and `sorter`, > leaving only `reducer` and `mapper`. Thought, we can filtering and sorting > before `array_group`, but i don't know whether it is as accurate as embedding > them into `array_group` or not. If not, we have to iterate manually, do > filtering and/or sorting, then reducing/mapping. > > > > > https://wiki.php.net/rfc/comprehensions > > https://wiki.php.net/rfc/pipe-operator-v2 > > Of course these are wonderful proposals. Yes, they are superior. To be honest, > I really hope they are landed in PHP. I already imagine what part of my code > will be replaced by them. Since I am not a C coder and totally blind about the > engine, I don't have my own opinion whether we lost good things or not, by not > adding them to PHP. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php >
  116624
December 12, 2021 12:40 7snovic@gmail.com (Hassan Ahmed)
I already added a new function `array_group`, any further
comments/thoughts will be highly appreciated.

Regards,
~Hassan

On Wed, Dec 8, 2021 at 11:35 AM Hassan Ahmed <7snovic@gmail.com> wrote:
> > Hendra Gunawan IMHO your suggestions is not related to > `array_group()`, you are talking about a great change in PHP as > mentioned by Larry, since we can have `Array($input, group(), > reducer(), mapper(), filter() ..... and so forth);` or even any other > way to handle the list comprehensions. but for array_group I think > that we should keep it to the minimal, to only group array. > > ~Hassan Ahmed > > On Wed, Dec 8, 2021 at 1:26 AM Hendra Gunawan > metal@gmail.com> wrote: > > > > > > > > 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 > > > > You can modify it slightly if you eager to: > > > > array_group( > > ... > > null|int|string|array $index_key, > > ... > > ): array > > > > If You provide `null`, it will operate on a bare array, no grouping involved. > > As a consequence, users have to provide `reducer` or `mapper`. So virtually, > > You design `array_group` to swallow `array_reduce` and `array_map`. Though, > > `array_map` is actually a different API compared to `array_reduce` or > > `array_group`. > > > > Interestingly, you will get a better quality of code if you include `reducer: ` > > and `mapper: ` consistently, whatever array level you work with. > > > > // `array_reduce` and `array_map` alternative > > array_group($array, null, reducer: $fnReducer); > > array_group($array, null, mapper: $fnMapper); > > > > array_group($array, "level1", reducer: $fnReducer); > > array_group($array, "level1", mapper: $fnMapper); > > array_group($array, ["level1", "level2"], reducer: $fnReducer); > > array_group($array, ["level1", "level2"], mapper: $fnMapper); > > > > I hope there is no bias between the proposed name (`array_group`) and its > > functionality. > > > > > > > > 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: > > > > Not a swiss army knife, just a penknife. AS i wrote before, it is just a > > shortcut. If you really mind about that, we can cancel `filter` and `sorter`, > > leaving only `reducer` and `mapper`. Thought, we can filtering and sorting > > before `array_group`, but i don't know whether it is as accurate as embedding > > them into `array_group` or not. If not, we have to iterate manually, do > > filtering and/or sorting, then reducing/mapping. > > > > > > > > https://wiki.php.net/rfc/comprehensions > > > https://wiki.php.net/rfc/pipe-operator-v2 > > > > Of course these are wonderful proposals. Yes, they are superior. To be honest, > > I really hope they are landed in PHP. I already imagine what part of my code > > will be replaced by them. Since I am not a C coder and totally blind about the > > engine, I don't have my own opinion whether we lost good things or not, by not > > adding them to PHP. > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > >
  116582
December 7, 2021 03:26 the.liquid.metal@gmail.com (Hendra Gunawan)
> > Better map/filter/reduce primitives in PHP would be dandy, but they have > nothing to do with array grouping. They're a separate operation that should > be composed with grouping. Packing them all into a single function sounds > like a terrible idea. > > If we wanted that... that's called list comprehensions, which I would > support and even tried to rally support for a few years ago, but got met > with a big shrug. :-)
We can imagine that `array_group` is just a shortcut to: do grouping, and then do reducing. (common to me) OR: do filtering, then do grouping, and the last do reducing. (less common to me) OR: do sorting, then do filtering, then do grouping, and the last do reducing. Best Regards Hendra Gunawan.
  116576
December 6, 2021 10:33 marandall@php.net (Mark Randall)
On 05/12/2021 14:02, Rowan Tommins wrote:
> Since this is explicitly an open question in the current RFC draft, it > seems a bit premature to talk about voting, rather than encouraging the > RFC to develop in a particular direction.
I hope it was taken as nothing more than an indication that adding an extra argument to array_columns would not be our preference for the route to go down :-) I could see the benefits to a standalone array_column_group function, that way the expected dimensions of the output would be more easily recognisable without having to inspect the parameters. As this RFC focuses heavily on array_columns, including all of the examples and the PR, I would encourage the author to consider an RFC specifically for array_column_group. Mark Randall