Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120354
MIME-Version: 1.0
References: <CADK1yX+aYifoOTwPGnuL3=xDL_NYgFgvZmFAvBfOK333Ohxwrw@mail.gmail.com>
 <000201d9897f$aa9f9fa0$ffdedee0$@roze.lv> <CADK1yXK4U=-POE2h5zu5de1NS0pQE7Rppa6QNxboEeRuOMDYJw@mail.gmail.com>
 <CALKiJKpyfhKB8yQ2us5LyUsk7RfM1fdgLCNHDpcAL6vHeXgD-A@mail.gmail.com>
 <CADK1yXJPyAes4UeNSTasX_ri4yJrLfSVhg7W=RL1iYknBRT6Wg@mail.gmail.com>
 <CALKiJKq+0fOc7=8zX_gZWQ395jHV3BUKKMEXNwc5yZEbmJEC_A@mail.gmail.com>
 <CADK1yXLDNf9dKu21uZbAqpCvu152N15faEu9N74Zr-DdegMgng@mail.gmail.com> <3021A824-1EDC-4523-814A-A0DA8187F068@gmail.com>
In-Reply-To: <3021A824-1EDC-4523-814A-A0DA8187F068@gmail.com>
Date: Thu, 18 May 2023 23:00:33 -0300
Message-ID: <CADK1yXL1m+zjCeAD713=P5eBHOYcO4BC8fraroiEX4EcdFWTBw@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000770b5d05fc024bb4"
Subject: Re: [PHP-DEV] PHP Package for PHP
From: deleugyn@gmail.com (Deleu)

--000000000000770b5d05fc024bb4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 18, 2023 at 6:56=E2=80=AFPM Rowan Tommins <rowan.collins@gmail.=
com>
wrote:

> On 18 May 2023 20:15:44 BST, Deleu <deleugyn@gmail.com> wrote:
> > I meant exactly the opposite. Monolog is an example of what PHP (is
> missing
> > =3D=3D=3D doesn't have enough of). There's hardly any reason to re-rele=
ase 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 th=
at
> > 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; th=
e
> 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 sam=
e
> 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.


--=20
Marco Deleu

--000000000000770b5d05fc024bb4--