Re: [RFC][DISCUSSION] Object-oriented curl API v2

On Fri, Jun 27, 2025, at 8:01 AM, Deleu wrote: > On Fri, Jun 27, 2025 at 9:24 AM Jordi Boggiano <j.boggiano@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