On Thu, Jun 26, 2025 at 11:27 Eric Norris <eric.t.nor...@gmail.com> wrote:
> Hello Internals, > > I'd like to formally propose a restart of the original object-oriented > curl API RFC (https://wiki.php.net/rfc/curl-oop): > > https://wiki.php.net/rfc/curl_oop_v2 > > The prior RFC seemed to get positive feedback, with a small consensus > around wanting enum(s) for curl options. I've taken that feedback and > incorporated it into a new RFC, as I am not the original author, but I > am interested in making another potential improvement to the curl > extension. > > In a nutshell, this version of the RFC: > > - uses enumerations for curl options and other curl constants > - introduces a new Curl namespace > > I have not yet created an implementation PR. I realize that is > somewhat discouraged, but I believe that this should be relatively > straightforward to implement (there's also the previous RFC's PR to > build on top of). The implementation of this RFC as it is now will > likely be tedious, however, so I'd like to get feedback on the > enumeration idea before committing to the work. > > I've outlined one open question in the RFC, which relates to the above: > > - Should we organize the curl option enumerations by value type? Or > have a single enumeration for all curl_setopt options and another for > all curl_multi_setopt options? > > If others (including the original RFC author) are interested in > working with me on this, I'm more than open to that, so please let me > know. > > Thanks, > Eric IMO, this sounds like something that would be great to start as a userland OOP wrapper for cURL, where it can be iterated on and the interface can be tested and changed much quicker. Then, maybe proceed to an external extension that can be migrated into core later, once its interface is stable. cURL is massive, and there are a lot of moving parts. I wouldn’t expect to get the API correct on the first try. :-) Cheers, Ben
