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
