On Fri, Jun 17, 2022 at 6:14 PM Sara Golemon <poll...@php.net> wrote: > > On Thu, Jun 16, 2022 at 2:10 AM Pierrick Charron <pierr...@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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
