Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116586
MIME-Version: 1.0
References: <CAL8UiQVrhOOivTL4LX+j-UXe=Scn_JwJ=zQwxga+K9kjWa2weA@mail.gmail.com>
 <CADyq6sJkLY2exHAczq9wXoPccDydnMaggfKCNSrP-ziHwhBmEA@mail.gmail.com>
 <61ac9759.1c69fb81.b0241.1e6fSMTPIN_ADDED_MISSING@mx.google.com>
 <d7d07ab1-b2cf-1391-30cf-614d71cc16b7@gmail.com> <CAL8UiQVvyze26W4ePwUm+EB5A95-Mu0-wgcKOqRcrSRw0kgxEA@mail.gmail.com>
 <268F5B4F-4770-48AA-B212-DE23116BCF4C@gmail.com> <CAL8UiQVmvab_cDs0ON7+fE+7dccST+=tCBgtpK+E9N-0Bzrxww@mail.gmail.com>
 <CAG4FTXzuK-k65w2KMzrA7vorJR1ARZRapH+j7Pdkp-dEo9H8vw@mail.gmail.com>
 <2e4dd298-77a1-4c40-ba31-1c9b7ebe1bb1@www.fastmail.com> <CAG4FTXymi=sqzdO=dnKC+ETLUxLoOFbKXZ=Jynspkm9QjAXaYA@mail.gmail.com>
 <CAL8UiQWbu1Qi+D=dxv9YknfpQJaQ0a5ye=iEU1ZX0xOWOm32jw@mail.gmail.com>
 <1b5790ec-1ffb-461e-b3fc-91d59a6db831@www.fastmail.com> <CAG4FTXwFREP0A7oGPJnAs2mKiykHCm55KvGWYv-OFHhQA51McA@mail.gmail.com>
In-Reply-To: <CAG4FTXwFREP0A7oGPJnAs2mKiykHCm55KvGWYv-OFHhQA51McA@mail.gmail.com>
Date: Wed, 8 Dec 2021 11:35:11 +0200
Message-ID: <CAL8UiQXX0rvjeAup-Hq3QJsdptVVeXekvabT-RyGvjTJwbR2Qw@mail.gmail.com>
To: Hendra Gunawan <the.liquid.metal@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] RFC [Discussion] array_column results grouping
From: 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
<the.liquid.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
>