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
