On 26.06.2025 18:25, Eric Norris wrote:
- uses enumerations for curl options and other curl constants

Overall I think the RFC is a good opportunity to clean up a few legacy oddities in the curl API, but I need to throw in my 2c about enum usage here, as someone that has actually implemented some complexish curl-based client [1].

Currently the API is:

    curl_setopt($h, CURLOPT_SMTH, 3);

Now moving this into multiple enums to me brings one major issue, that I first have to think about which type the option has to then know on which enum I find it.

I understand this brings type safety on the value side if you have multiple setOptionInt etc, but that does not seem worth the trade-off to me. Type safety can already be done in static analyzers as they can see which option you pass in, they know which value should be allowed.

Then on top of that, assuming we'd put all options in one enum.. I am still wondering what the added value is compared to simply having the global constants (they could be namespaced if anything...). It's longer to type, and does not provide any better autocompletion. \Curl\Option::ConnectTimeout vs CURLOPT_CONNECT_TIMEOUT sounds ok to me if people feel strongly pro-enum, but I do really hope it is then a single enum + setOption() call.

Best,
Jordi

[1] https://github.com/composer/composer/blob/main/src/Composer/Util/Http/CurlDownloader.php

Jordi Boggiano
@seldaek - https://seld.be

Reply via email to