On Thu, May 18, 2023 at 6:56 PM Rowan Tommins <rowan.coll...@gmail.com> wrote:
> 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, 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. Let me start from here where we agree on. We start by designing a new PHP package to wrap cURL. Bear in mind for a minute that I started this thread with the intention of lowering the barrier of getting RFC approved and the code being maintained by PHP developers. After some good amount of bikeshedding we approve the first PHP package. It is fully covered by automation tests so that future maintenance is relatively easy. It gets released under the namespace Php\8.4\Curl. I'm going to be greedy here and assume we even get it bundled inside PHP. Before PHP 8.4 gets released we also work on Php\8.4\Strings package. For the sake of argument let's pretend that within 1 month of PHP 8.4 release we discover that the Curl package was actually really bad and we decide to rework it. A new RFC is approved and we bundle a new design under Php\8.5\Curl. Meanwhile Strings was a success and no new version is warranted. So Php\8.5\Strings does not need to exist. Now both new designs are still great and Php\8.6\Curl and Php\8.6\Strings do not need to exist either. Perhaps someone raises an RFC so that PHP 8.7 will unbundle/eject Php\8.4\Curl and keep only Php\8.5\Curl inside PHP. It's a breaking change, but one that just means we now move the code to being Composer-only instead of bundled inside PHP. It's a "deprecated" package that can just exist on GitHub for backwards compatibility. A few more years go by and another RFC comes in to abandon Php\8.4\Curl from the PHP Group. This whole story, from a user standpoint, screams stability. If a project starts using Php\8.4\Curl and gets so deep into it that it's too expensive for them to upgrade, they can just keep using it without upgrading to the 8.5 counterpart while still upgrading their PHP binary. If it gets unbundled, they can just `composer require` it. If years go by and the package gets abandoned, they can still fork it and pretty much no code change would be necessary. With namespaces, PHP Packages get to do "Editions" without all of the complexity of doing editions at the engine level. Written in PHP, it can easily get ejected out of the PHP binary and still be "backward-compatible". PHP seems to be at a corner where it's best not to do anything than to make another mistake. A mistake made in the design of the language takes decades to undo. I believe we can improve the language's basic functionality this way and slowly grow into wrapping most features needed by the majority of web applications. We could start with just wrapping libcurl in a nicer API and if it works out great we could do more until one day we end up even providing a slim HTTP Client. The PHP community as a whole (regardless of which framework camp you are in) as well as newcomers could only benefit from it. -- Marco Deleu