Re: [RFC] OOP API for cURL extension

From: Date: Thu, 15 Feb 2024 07:14:31 +0000
Subject: Re: [RFC] OOP API for cURL extension
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-122377@lists.php.net to get a copy of this message
Am 15-Feb-2024 03:30:44 +0100 schrieb pollita@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

« previous php.internals (#122377) next »