Re: [RFC] OOP API for cURL extension

On 15/2/24 05:47, Sara Golemon wrote:

Good afternoon folks, I'd like to open discussion on adding OOP APIs to the cURL extension. https://wiki.php.net/rfc/curl-oop Thanks for making this. It's certainly an improvement, but it's disappointing to see such a conservative change when the extension interface is so weird and awkward. I'm sure you know what I mean.

It's easy to forget how bad it is until you have to do something without a framework, or explain it to a new developer. I guess the proper fix would be to add a new extension with new names for everything, with Request and Response objects, along the lines of PSR-18. But if I can think of a few minor backwards-compatible changes which would improve things a bit. For example, getInfo() could be split out to separate read-only properties. And setOpt() could be split out to separate chainable mutator methods. That would improve type inference in surrounding code. I see CurlHandle::exec() does not have the same return value as curl_exec() in your proposal, since errors are promoted to exceptions. But it still has a union return type. I would take it one step further, and have it unconditionally return either a string or void. Having it return a string is defensible if you consider it to be returning the final value of the body buffer. Enable CURLOPT_RETURNTRANSFER by default. If CURLOPT_WRITEFUNCTION or CURLOPT_FILE is set and thus the buffer doesn't get appended to, naturally curl_exec() will return an empty string. -- Tim Starling