Re: [RFC] OOP API for cURL extension
| From: | Christian Stoller | 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