Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120339
MIME-Version: 1.0
References: <CADK1yX+aYifoOTwPGnuL3=xDL_NYgFgvZmFAvBfOK333Ohxwrw@mail.gmail.com>
In-Reply-To: <CADK1yX+aYifoOTwPGnuL3=xDL_NYgFgvZmFAvBfOK333Ohxwrw@mail.gmail.com>
Date: Thu, 18 May 2023 15:41:46 +0200
Message-ID: <CANS-=pc23kFOHNr-+k1YSE-ROyVcBdYDWzYJTt-Ri5SPSO3z+A@mail.gmail.com>
To: Deleu <deleugyn@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ce147905fbf7f89c"
Subject: Re: [PHP-DEV] PHP Package for PHP
From: kjarli@gmail.com (Lynn)

--000000000000ce147905fbf7f89c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 18, 2023 at 3:07=E2=80=AFAM Deleu <deleugyn@gmail.com> wrote:

> Hi folks!
>
> Reading through https://externals.io/message/120323#120326 and
> https://externals.io/message/120323#120332, it reminded me of a few times
> I've seen similar debates on internals about "why not do this on userland=
?"
> and the consensus seems to be inclined to only take the maintenance burde=
n
> of internals function if there's strong justification for it regardless o=
f
> whether there's consensus of being useful or not.
>
> Which begs the question of a PHP Package for PHP. Some benefits:
>
> - Written in PHP, it will allow a much wider pool of contributors than th=
e
> scarce pool of C developers contributing to PHP source code.
> - Being official means it inherits the trust PHP already has
> - Green field development in this day and age often comes with a great se=
t
> of automation tests that drastically lowers the maintenance burden
> - Possibility to standardize a lot of common code that has countless
> userland implementations
> - If we make a mistake of implementing a bad design, the worst thing migh=
t
> be that we "wasted" a good word in a function or class name. As long as
> test coverage is there we can probably just keep it running for many year=
s
> with little negative impact other than "yeah, PHP did a bad job at X".
>
> Such a project could benefit from the RFC process already in-place and
> voters could take into consideration the lower maintenance burden when
> voting for something that they think it's useful.
> One relevant downside is that internals might get flooded with RFCs for
> filling up some common functionalities for a few years until it dials dow=
n
> a bit.
> It may also lead to re-discussing PHP's entire standard library.
>
> The work to get started seems to be about:
>
> 1- Getting an RFC to approve this idea itself
> 2- Getting a repository to host the PHP package code.
> 3- CI/CD
> 4- Release Management
> 5- Versioning Strategy
> 6- Package naming convention
> 7- Distribution strategy (single package vs multiple sub-packages)
> 8- PHP developers and community contributions
>
> Anything I'm missing? Thoughts?
>
> --
> Marco Deleu
>

A few more benefits:
 - an official php polyfill package to be forward compatible with new
classes/functions/constants for core php
 - popular features could eventually be ported to C if it gives a benefit
in performance, or if they are really popular
 - applications with slower upgrade cycles would have less effort
implementing new php features

--000000000000ce147905fbf7f89c--