On 18 May 2023 20:15:44 BST, Deleu <deleu...@gmail.com> wrote: > I meant exactly the opposite. Monolog is an example of what PHP (is missing > === doesn't have enough of). There's hardly any reason to re-release it > under the PHP umbrella. Monolog already won the log battle. I can't say the > same for virtually anything else, to be honest. Some folks might say that > Guzzle won the HTTP battle, I just disagree and think we could have > something better by default
Let's look at HTTP clients then. PHP is certainly lacking a good one built in. Using streams with allow_url_fopen is serviceable for fetching a page, but not much else; the curl functions are ... embarrassing. On the other hand, Guzzle has gone through 7 major version bumps in 12 years, presumably believing that each improvement justified the disruption to users. And even then, as you point out, Symfony decided to write their own HttpClient component. Clearly, they didn't do that because they didn't know Guzzle existed; presumably, they thought it still wasn't good enough. An extension or library fully bundled with PHP would have no hope of competing with that. A major version could only be made every 5 years, and even then breaking changes have to be minimised, so we would really have one chance to somehow improve on what others have spent years refining. On the other hand, a clean API with a much smaller feature set, which could be used on its own for simple use cases, and be the low level implementation for Guzzle, Symfony HttpClient, etc, would be extremely useful. In other words, an overhaul of the curl functions to give the same flexibility, but an API that feels more native to PHP, rather than a thin wrapper around the C functions of libcurl. Whether it would make sense to do that in PHP, I'm not so sure. It would mean that any fundamentally new feature would need implementing twice: once in C, in the existing clunky API, then again in PHP, to wrap it into a different style. On the other hand, it would make polyfilling the new API trivial, and have a wider pool of contributors who could work on it - as long as they didn't hit a limitation that needed to be fixed in the C layer. Regards, -- Rowan Tommins [IMSoP]
