Hi Marco On Thu, May 18, 2023 at 7:35 PM Rowan Tommins <rowan.coll...@gmail.com> wrote: > > On Thu, 18 May 2023 at 16:27, Deleu <deleu...@gmail.com> wrote: > > Monolog is a great example of what PHP is missing - a single library for a > > purpose. I have never worked with any other library besides Monolog and I > > never worked on any project which didn't have it installed. Perhaps my > > bubble might be a limiting factor here, but I get a feeling that Monolog is > > considered to be The Logging PHP Library. > > > > > Then in what sense is it "missing"? What value would be served by placing > an elephant logo on it, and renaming it "PHPLog™"? > > I know that's a bit of a sarcastic response, but it's also a serious one - > what would we define as the aims of a replacement for Monolog, which aren't > currently being served? > > We could guarantee it was installed with every version of PHP, but only by > severely restricting its release cycle, so that every PHP version had > exactly one version of Monolog. If it remains an independently versioned > Composer package, I can't think of much that would change.
I fully agree with Rowan. These packages have had many years to get to where they are, and are maintained by capable people. Putting an official stamp on them doesn't make them qualitatively better. I could see an argument being made for bundling them with PHP so that Composer is not required, but that does not seem smart for large libraries that need the freedom to evolve. I'm absolutely in favor for a more complete standard library in terms of basic operations, e.g. better iterator support. > > Laravel's `Arr` class also didn't get scrutinized by PHP RFC so there's no > > way to know whether it's all good, some good or all bad. > > > > > I don't think PHP's decision-making process can be held up as a shining > example of good governance, in contrast to everyone else's anarchy. I don't > know much about Laravel's governance, but I am quite sure every change is > discussed and iterated on before release. In fact, they probably have a > whole bunch of standards and processes that PHP is lacking, and would have > to invent to make any new library a success. Moreover, I believe the main barrier for adding new functions to PHPs standard library is not C but the RFC process itself. "Trial and error" is much easier than making 50+ people agree on the correct solution on the first try. I suppose something we could try is an "official but experimental" Composer package for testing new classes/functions for the standard library before stabilizing them and rewriting them in C. Maybe this could prevent some of the bike-shedding. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
