Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120499
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
In-Reply-To: <f06c2023-b49d-4368-b7b1-306f0334ea52@app.fastmail.com>
Date: Thu, 1 Jun 2023 11:56:19 +0200
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <40AD8627-C7EC-4FD9-B47E-8F3A8B8737BE@gmail.com>
References: <289E585B-EF8B-4B17-89BE-BE8295FD9FE1@gmail.com>
 <CAAKU0u=r_V4h1xw=nTGUmHzEErS+UMHOx100LKLf40jz_MEV1A@mail.gmail.com>
 <5FE9216F-A84D-4482-A22E-05A44C2A9A3C@gmail.com>
 <f06c2023-b49d-4368-b7b1-306f0334ea52@app.fastmail.com>
To: Casper Langemeijer <langemeijer@php.net>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add new function `array_group`
From: buritomath@gmail.com (Boro Sitnikovski)



> On 1.6.2023, at 09:18, Casper Langemeijer <langemeijer@php.net> wrote:
>=20
> On Thu, Jun 1, 2023, at 01:19, Boro Sitnikovski wrote:
>> Thank you for the information and encouragement! I was a bit scared =
of this one being rejected too, but still decided to give it a shot :)
>=20
> As an alternative approach this is what I would do in your situation:=20=

>=20
> I would start with a PHP implementation, gather some opinions on what =
this method would do, how it should work. Finalising the functional =
specification to a point where you find broad acceptance. This would =
also allow others to help performance optimise your implementation.
>=20
> Then start a PECL extension implementing the exact same thing in C =
code. This could start as a niche for people that really need the extra =
performance the extension would bring, possibly grow out to something =
that is defacto standaard.
>=20
> PECL extensions are documented in the PHP manual, so the manual could =
have your array_group() function described, possibly with a reference to =
the original PHP implementation/ polyfill.
>=20
> This approach minimises dependence on internals giving a green light =
and maximises the possibility to work with others as a team on this. It =
would give you a chance to prove that the solution you provide is =
actually wanted by users. If that really is the case, if it came to vote =
to merging the extension into PHP itself the vote could be different =
than the vote on the former RFC.
>=20
> Greetings, Casper

Thank you for the suggestion, I like this approach and it's definitely =
much "safer" than going with an RFC for core directly.

What are your thoughts on creating a PECL extension called `array_utils` =
(selling point would be high performance array utils or something), =
which in the future might contain more than `array_group*`, and the =
approach would be to cherry-pick those functions that have frequent =
usage in codebases into core? Or would it be better to stick to a =
particular/more concrete extension?=