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

Reply via email to