RE: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2
-----Original Message-----
From: Eric Norris <[email protected]>
Sent: Thursday, June 26, 2025 7:25 PM
To: PHP internals <[email protected]>
Subject: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2
> I'd like to formally propose a restart of the original object-oriented curl API RFC
Cool. Calling functions with object as an argument to modify it's state feels very C-ish and
wildly different from how contemporary PHP is usually written. So even a 1:1 translation into a more
familiar API is welcome.
It still feels a bit unfamiliar to me that part of the response (the body) is returned from
execute() while the other stuff (like the status code) is stored in the state of the
Handle instance. Is this statefulness suggested by libcurl and reflects it's object? Or is it a
choice on the PHP side? I'm just wondering, this is probably not something that should be
changed on the Handle class but maybe on some new layer.
The enums that you propose are backed. It seems appropriate in the sense of continuity, but is there
a need for that? I'd argue that option names like AbstractUnixSocket or AutoReferer are values
per se and there is no usable meaning for those integer values behind them. Maybe the translation to
numeric constants (assuming it's necessary) can be done internally (in the Handle) via a
match or switch statement and let's have pure enums?
I see that the option setters return \Curl\Handle, but it is a bit unclear whether it
will actually return static, self or $this. I assume the
latter but it would be nice to document that we're mutating the same object.
> 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?
In fact I would expect a single ->setOption() instead of the type specific ones.
Having to specify the argument type in the setter name and/or the enum name doesn't sound very
enjoyable to me.
BR,
Juris
Thread (21 messages)