> On 1.6.2023, at 09:18, Casper Langemeijer <langemei...@php.net> wrote:
>
> 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 :)
>
> As an alternative approach this is what I would do in your situation:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
