Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127805
Precedence: bulk
MIME-Version: 1.0
References: <CA+NMNO0K85acCismdBL=8vr5=nKg1_-i0BjXyiqnjoqGAnH3Xw@mail.gmail.com>
 <CANLbj-ppn+QtYij2uHXmNvbXckKzz84fkj6f-6iw_7wioFN0dA@mail.gmail.com>
In-Reply-To: <CANLbj-ppn+QtYij2uHXmNvbXckKzz84fkj6f-6iw_7wioFN0dA@mail.gmail.com>
Reply-To: erictnorris@gmail.com
Date: Mon, 30 Jun 2025 11:32:54 -0400
Message-ID: <CA+NMNO2N3G_YbrjOk5-4sfAVAiCz7XaU_Nd5M+MvuiR4RJyUPw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2
To: Ayesh Karunaratne <ayesh@php.watch>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
From: eric.t.norris@gmail.com (Eric Norris)

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.