On Thu, May 18, 2023 at 3:07 AM Deleu <deleu...@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 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 >
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
