Am 15-Feb-2024 03:30:44 +0100 schrieb poll...@php.net: > Good afternoon folks, I'd like to open discussion on adding OOP APIs to the > cURL extension. > https://wiki.php.net/rfc/curl-oop > > This has been a long standing bug-bear of mine, and I think its time has come. > > try { > (new \CurlHandle)->setOpt(YOUR_VOTE, true)->exec(); > } catch (\CurlHandleException $ex) { > assert(false); // Why not?! > } > > -Sara
Hi Sara, I like your proposal generally. But I'd suggest to rethink the names of the methods. I understand that you want to reuse the same names of the procedural version and the underlying lib. But this is the chance to optimize the naming and reduce inconsistence. In the future this will become harder. For example there is the getter "getInfo" and some getters without the "get" prefix, like "errno", "error" and "strerror". I'd suggest to unify them. Either use the "get" prefix for all of those or for none. Personally, I have no particular preference for one of the two options. The second thing I propose to change is the usage of abbreviations. I'd suggest the following mapping for methods of CurlHandle: - errno => errorNumber or getErrorNumber - error => errorMessage or getErrorMessage - strerror => errorMessageByNumber or getErrorMessageByNumber - exec => execute - setOpt => setOption - setOptArray => setOptionArray There may be better proposals from others. What do you think? Best regards, Christian