On 19 June 2022 03:53:17 BST, Pierrick Charron <pierr...@php.net> wrote: > >I hope you don't mind, I took some of your code from your "Enable >strict_types checking for curl_setopt()" pull request [1] to do some test >on introducing this but only on the OOP API. It's working very well [2]. >Can I know why this PR was closed ? Any issues ? Or was it more because it >was too much of a change for the procedural API ?
While a few type errors there might be useful, it still feels a bit like polishing a turd. I count about 180 different options that can be passed to curl_setopt. Some of them are used by nearly every user of PHP, and some are for very obscure niche uses. Many of them are useless on their own, and exist only to tweak the behaviour of some other option, or need to be used in groups like usernames and passwords. Others have unintuitive and unhelpful defaults, that need to be overridden with a different option. The manual page has long topped the league table for user comments, currently standing at 102. It is simply not a practical design for what most users of PHP need. I think one way out of this mess is to start grouping options together, and providing specific methods to set them, with named, type-safe parameters. For instance, CurlHandle::setProxyOptions(string $url, ?string $authUserName, ?string $authPassword, ...) and so on. If the long lists of parameters still feel a bit messy, we could go a step further and make objects for building sets of options, with methods taking short lists of genuinely dependent options, e.g. CurlProxyOptions::setAuth(string $userName, string $password) and CurlProxyOptions::disableAuth() Some of the options should be rethought in the process to make more sense to PHP's common usage, rather than libcurl's. As just one example, enabling CURLOPT_VERBOSE sends some debug information to stderr, but on a web server that is normally a log file where it will be mixed in with other information. To capture it instead you need to also set CURLOPT_STDERR, which requires an open file handle. What most users *actually* want is for that information to be available to them as a string after the request is executed. Another thing that might be useful is some new factory methods that set sensible defaults, like CurlHandle::createForHttp(string|CurlUrl $url, string $method) If we can build these things on top of the existing CurlHandle, we can release a few things first, and progressively add features. Rather than having to decide which extension to use, users will still have access to curl_setopt for things there isn't a nicer interface for yet. We can even leave it in place as something like CurlHandle::setRawOption for when users want fine control of the library, or some really obscure setting. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
