Thanks for your response Ayesh! I hope to see this RFC on php.watch :) > However, I softly oppose this RFC in its current state and the way it > seems to be going. > > I have pushed Curl and libcurl to some uncommon cases such as HTTP/3, > DoH, the new debug callback (which I authored the PR for), IMAP, and a > few other obscure tweaks. For all of them, the current `curl_setopt` > worked, and the more I used it, the more I understood that having just > a few Curl functions and a sea of Curl options is the least > "presumptive way", regardless of the protocol and the options Curl > provides. > > The extension is named `Curl`, because it's supposed to provide Curl > functionality into PHP. It provides low-level functionality, but we > should leave it to the PHP users to build the libraries that have > fluent APIs.
It would be helpful for me to understand what specifically you are objecting to in the current discussion, putting aside the suggested enumeration changes. Do you object to any HTTP-oriented methods at all, like something to set the HTTP method? Would you object to methods that apply to all, or nearly all, transport types, like a setTimeout() method? > I think a more light-weight approach would be to: > > - Move all of them to the `\Curl` namespace. > - Rename Curl options to `\Curl\Option` namespace, and rename them, > so that `CURLOPT_SSL_VERIFYHOST` becomes `Curl\Option\SSL_VERIFYHOST` > - Rename Curl error codes to similar `\Curl\Error` constants. > - Have the `CurlHandle` object accept options, e.g. > `$ch->setOption(Curl\Option\SSL_VERIFYHOST, 2)`. libcurl Easy handlers > do not have a way to retrieve the option once it's set, so there will > be no `getOption` either. > - Make Curl throw exceptions, and never `false` on `\Curl\execute()`, > with the Exception's error code and message mapped to the Curl error > code and message. We will not need to bring over `curl_error` or > `curl_errno` functions. Acknowledged, thank you. The RFC does propose what you're suggesting with never returning false and instead throwing exceptions, but it feels like it might still be useful to have properties on the actual object. Do you have opinions on that? > Realistically, I don't think we can deprecate and remove the `\curl_*` > functions any time soon, so this will actually add more maintenance > work for php-src at the end too. Agreed, I do not plan on suggesting this, not even under Future Scope.
