On 5/18/23 9:00 PM, Deleu wrote:
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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
