-----Original Message----- From: Eric Norris <eric.t.nor...@gmail.com> Sent: Thursday, June 26, 2025 7:25 PM To: PHP internals <internals@lists.php.net> 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
