Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120356
Message-ID: <f961269d-ea97-3dbf-3f57-198d020a687f@gunnard.org>
Date: Thu, 18 May 2023 23:50:28 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.11.0
Content-Language: en-US
To: internals@lists.php.net
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>
 <CADK1yXL1m+zjCeAD713=P5eBHOYcO4BC8fraroiEX4EcdFWTBw@mail.gmail.com>
In-Reply-To: <CADK1yXL1m+zjCeAD713=P5eBHOYcO4BC8fraroiEX4EcdFWTBw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] PHP Package for PHP
From: gunnard@gunnard.org (Gunnard engebreth)


On 5/18/23 9:00 PM, Deleu wrote:
> On Thu, May 18, 2023 at 6:56 PM 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
>>> === 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.
>
>

>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 think this is a bold statement about the state of PHP and should have the backing to hold it up.

>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.

php and curl are two seperate "things" entaties if you will, libcurl works very well on its own.
I hear you in your want to have a united community of frameworks but as of now, php is (and correct me if I am wrong in projecting this) is a community that helps to provide ways to use PHP in usefull environments.

"
PHP seems to be at a corner where it's best not to do anything than to make
another mistake.
"
I think you are more on the money than you are not... but this does not mean that PHP is in anyone's pocket