Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117998
MIME-Version: 1.0
References: <CAOfKkdRzoo7JuD07F8nkZBYvS5eDMiV2r6cNV-FgeLxBrdCsiQ@mail.gmail.com>
 <CAESVnVpzqT0xtEShqQp+FPXt2DQjeAXpkSVZTACAC0CW=8FBBg@mail.gmail.com>
In-Reply-To: <CAESVnVpzqT0xtEShqQp+FPXt2DQjeAXpkSVZTACAC0CW=8FBBg@mail.gmail.com>
Date: Fri, 17 Jun 2022 23:00:43 +0200
Message-ID: <CAPzBOBM0xdsBy2c21jOyOukL-UBnA3iB9=_-wQsbWQhiT=PyaA@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Pierrick Charron <pierrick@php.net>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements
From: landers.robert@gmail.com (Robert Landers)

On Fri, Jun 17, 2022 at 6:14 PM Sara Golemon <pollita@php.net> wrote:
>
> On Thu, Jun 16, 2022 at 2:10 AM Pierrick Charron <pierrick@php.net> wrote:
>
> > For a long time, ext/curl worked with handles as "curl resources" and
> > functions mapped to the libcurl functions, but since PHP8.0 "curl
> > resources" were converted to opaque classes with no methods. So my main
> > goal here is to come up with a solution for the new Curl URL API, but maybe
> > also to be consistent, make some changes to existing curl classes like
> > `CurlHandle` to add methods and improve the current state of the extension.
> >
> >
> This is so bizarre, I *know* I wrote an OOPified cURL extension some years
> ago (called it curli), and now I can't find it anywhere.  What universe am
> I even in?
>
> Anyway, +1 on making a whole new OOPified cURL implementation.    $ch =
> (new CurlHandle($uri))->setOpt(Curl::OPT_METHOD, 'post')->perform();
> Let it throw exceptions, do proper type checks, all the goodness.  Let the
> procedural APIs behave differently than the object methods and that's okay.
>
> cURL is a foundational extension in PHP and I respect the choices that were
> made in its API design, but it's 2022, and we deserve a better ext/curl.
>
> -Sara

Also, would it be unreasonable to ask it to take advantage of the
Fiber constructs if in a Fiber context? That would be simply amazing
if this high-level OOP implementation were async-ish by default.

If anything should get native Fiber superpowers, it should be this
extension, IMHO. Also, IMHO, this is an unreasonable request, but
perhaps a separate RFC once this original proposal is accepted and
figured out?