Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117977
MIME-Version: 1.0
References: <CAOfKkdRzoo7JuD07F8nkZBYvS5eDMiV2r6cNV-FgeLxBrdCsiQ@mail.gmail.com>
 <b8333cb6-eaa0-4170-a3ba-29eadb2fd8fa@www.fastmail.com> <CAOfKkdSWhQ5-wbnnWzb74VknGNVSM+2+5-sMoc-_yOEzk4JFFQ@mail.gmail.com>
In-Reply-To: <CAOfKkdSWhQ5-wbnnWzb74VknGNVSM+2+5-sMoc-_yOEzk4JFFQ@mail.gmail.com>
Date: Fri, 17 Jun 2022 14:55:31 +0100
Message-ID: <CALKiJKqy2asFNUFb+JdFuTLwiLGWdhq+XvJhX482n5w8cTADdg@mail.gmail.com>
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000044417e05e1a51cf1"
Subject: Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements
From: rowan.collins@gmail.com (Rowan Tommins)

--00000000000044417e05e1a51cf1
Content-Type: text/plain; charset="UTF-8"

Hi Pierrick,


On Thu, 16 Jun 2022 at 22:44, Pierrick Charron <pierrick@php.net> wrote:

> Is it OK to have one part
> that is a thin wrapper and another part that is a "remodeling" of the API ?
> (This is not a rhetorical question, I really ask myself the question).
>


I agree with others that the new API should be exposed via a new,
well-designed object, with no procedural version or low-level equivalence
to libcurl.

Something that nobody's brought up yet is that the curl extension actually
already has a facility designed this way: CurlFile and CurlStringFile are
high-level PHP objects which allow users to interact with file uploads,
without any knowledge of what libcurl's API for them looks like.

I think it's perfectly reasonable for CurlUrl to be designed the same way,
regardless of what else we do with the extension.



> We could also keep the existing API as is and not improve it living only
> with the procedural API, but I think that with minimal effort, we could get
> some small (but still) benefits. Yes, CurlHandle for example would just be
> a wrapper on the procedural API that happens to use `->` and throw
> exceptions instead of returning null/false,  but one of the gains would be
> to help developers with autocomplete to find methods they can call on the
> handle.
>


This feels like a very small gain, since users can already type "curl_" and
get a list of all curl functions. It also has real costs: users may be
confused why there are two ways of writing the same thing; and it sets the
precedent that methods on CurlHandle should mirror curl_* functions, even
though we know those have terrible usability.

I think if we do add methods to the CurlHandle class, they should be
higher-level methods for common tasks that are currently unnecessarily
awkward. I don't think we'd need to add everything at once, just establish
some general design principles.

(I'm honestly surprised that CURLOPT_RETURNTRANSFER, and curl_setopt in
general, doesn't make it onto more lists of the worst parts of PHP.)

Regards,
-- 
Rowan Tommins
[IMSoP]

--00000000000044417e05e1a51cf1--