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. With that said, for me this also threads into the bikeshedding area that could spiral into a failed RFC. Be it a single Enum for everything, constants, context-based enums or type-based enums, I would much rather have this RFC than not have it. PHP is one of the most important Web applications in the world and it severely lacks the ability to simplify Http. We could take inspiration from Python Requests [1] or Node Fetch [2] as a really simple and straightforward API that covers the vast majority of cases. I take the point that we don't need to go all the way and invent a RequestClient library in PHP and this RFC is threading on the small step of converting Curl procedural API into OOP, which is where Larry and Rowans recommendations about some minor helper methods go a really really long way compared to where we are today. [1] https://www.w3schools.com/PYTHON/ref_requests_post.asp [2] https://nodejs.org/en/learn/getting-started/fetch#basic-post-usage -- Marco Deleu
