On Fri, Jun 27, 2025, at 8:01 AM, Deleu wrote:
> On Fri, Jun 27, 2025 at 9:24 AM Jordi Boggiano <j.boggi...@seld.be> wrote:
>> 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
>
> Reading this I can't help but feel like there's some cognitive bias 
> *because* you have written a Curl class yourself. The author of a PHP 
> Class that wraps Curl needs to know about every option and how to 
> translate them back-and-forth, which is really the insight I take from 
> your message. As a PHP developer making HTTP requests, I would never 
> have guessed 270 options for Curl configurations and having them split 
> into multiple Enums gives me smaller "boxes" that are easier to 
> mentally parse individually. With that said, splitting enumerations by 
> type rather than context does weaken the argument of split enums. I 
> wouldn't be instinctively looking for "what enum do I need that is an 
> int?" or "what enum do I need that is a string?" unless I already know 
> the implementation details by heart. The Info and Pause enumerations 
> seem more useful in that regard as they reduce the scope in which I 
> need to understand, process and decide. 

I will agree here.  Splitting enums by type doesn't add much value.  Splitting 
them by topic might, if the topics are sufficiently distinct that a separate 
method makes sense.  I don't know Curl's API well enough to make specific 
recommendations there.

--Larry Garfield

Reply via email to