Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120335
MIME-Version: 1.0
Date: Wed, 17 May 2023 22:06:26 -0300
Message-ID: <CADK1yX+aYifoOTwPGnuL3=xDL_NYgFgvZmFAvBfOK333Ohxwrw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000016e40d05fbed6c65"
Subject: PHP Package for PHP
From: deleugyn@gmail.com (Deleu)

--00000000000016e40d05fbed6c65
Content-Type: text/plain; charset="UTF-8"

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 burden
of internals function if there's strong justification for it regardless of
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 the
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 set
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 might
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 years
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 down
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

--00000000000016e40d05fbed6c65--