Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122430
Precedence: bulk
MIME-Version: 1.0
References: <CAESVnVp11-EVBrhzSj16=Nd3fYE366piq6fG-9wV3+iH8TxchA@mail.gmail.com>
 <CAESVnVpHRU8-Fc10XEdRkf3tU-5bXxO4tZ-CKwWJeUabB2LM4g@mail.gmail.com>
 <9bc2d842-5f56-4062-8b21-3b41310f2c86@app.fastmail.com> <FBA604F7-E7C5-443F-BD3C-CD9F2CE2A597@gmail.com>
In-Reply-To: <FBA604F7-E7C5-443F-BD3C-CD9F2CE2A597@gmail.com>
Date: Sun, 18 Feb 2024 16:26:37 +0100
Message-ID: <CANS-=pdZsR2y-2Z+cHVLFv=h2s+OBvJTn5LULUjOE05AR0i2xg@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: [RFC] OOP API for cURL extension
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000efbdab0611a99b23"
From: kjarli@gmail.com (Lynn)

--000000000000efbdab0611a99b23
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 18, 2024 at 12:41=E2=80=AFPM Rowan Tommins <rowan.collins@gmail=
.com>
wrote:

> On 17 February 2024 15:57:20 GMT, Larry Garfield <larry@garfieldtech.com>
> wrote:
>
> >The RFC would also benefit greatly from some practical examples of using
> the new API.  Right now it's not clear to me (as someone who almost never
> uses Curl directly) how/why I'd use any of these, since there's still "a
> whole crapton of int constants I don't understand floating around."  The
> suggestion to use an Enum (or several) here is a good one and would help =
a
> lot with that, so I'm +1 there.
>
> To my mind, the *eventual* aim should be that users don't *need* a
> userland wrapper just to make a simple request in a readable way, and tha=
t
> setting raw curl options becomes an advanced feature that most users neve=
r
> need.
>
> I know a lot of people's minds will immediately go to request and respons=
e
> objects, but I think we can go a long way by just making well-named metho=
ds
> wrapping one or two curl options each, so that you could write this:
>
> $ch =3D new CurlHandle('https://example.com');
> $ch->setMethod('POST');
> $ch->setRequestBody('{"stuff":"here"}');
> $ch->setBasicAuth('admin', 'correct-horse-battery-staple');
> $result =3D $ch->executeAndReturn();
>
> Note that I am not saying every one of those methods needs to be added
> right now; adding a few at a time may be sensible to have time to discuss
> good names and signatures. But to me, renaming CURLOPT_POSTFIELDS to
> Curl\StringOptionsEnum::POSTFIELDS doesn't get us very far - users
> shouldn't need a raw curl setting for such a basic feature in the first
> place.
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>

 Having a lot of setters for options might make it really hard to find the
methods you're looking for in terms of auto-complete in your IDE. Would it
make sense to split options into a separate object (or perhaps multiple),
that could in theory also be shared between different CurlHandle instances?

--000000000000efbdab0611a99b23
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sun, Feb 18, 2024 at 12:41=E2=80=
=AFPM Rowan Tommins &lt;<a href=3D"mailto:rowan.collins@gmail.com">rowan.co=
llins@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">On 17 February 2024 15:57:20 GMT, Larry Garfield &lt;<a href=
=3D"mailto:larry@garfieldtech.com" target=3D"_blank">larry@garfieldtech.com=
</a>&gt; wrote:<br>
<br>
&gt;The RFC would also benefit greatly from some practical examples of usin=
g the new API.=C2=A0 Right now it&#39;s not clear to me (as someone who alm=
ost never uses Curl directly) how/why I&#39;d use any of these, since there=
&#39;s still &quot;a whole crapton of int constants I don&#39;t understand =
floating around.&quot;=C2=A0 The suggestion to use an Enum (or several) her=
e is a good one and would help a lot with that, so I&#39;m +1 there.<br>
<br>
To my mind, the *eventual* aim should be that users don&#39;t *need* a user=
land wrapper just to make a simple request in a readable way, and that sett=
ing raw curl options becomes an advanced feature that most users never need=
.<br>
<br>
I know a lot of people&#39;s minds will immediately go to request and respo=
nse objects, but I think we can go a long way by just making well-named met=
hods wrapping one or two curl options each, so that you could write this:<b=
r>
<br>
$ch =3D new CurlHandle(&#39;<a href=3D"https://example.com" rel=3D"noreferr=
er" target=3D"_blank">https://example.com</a>&#39;);<br>
$ch-&gt;setMethod(&#39;POST&#39;);<br>
$ch-&gt;setRequestBody(&#39;{&quot;stuff&quot;:&quot;here&quot;}&#39;);<br>
$ch-&gt;setBasicAuth(&#39;admin&#39;, &#39;correct-horse-battery-staple&#39=
;);<br>
$result =3D $ch-&gt;executeAndReturn();<br>
<br>
Note that I am not saying every one of those methods needs to be added righ=
t now; adding a few at a time may be sensible to have time to discuss good =
names and signatures. But to me, renaming CURLOPT_POSTFIELDS to Curl\String=
OptionsEnum::POSTFIELDS doesn&#39;t get us very far - users shouldn&#39;t n=
eed a raw curl setting for such a basic feature in the first place.<br>
<br>
Regards,<br>
<br>
-- <br>
Rowan Tommins<br>
[IMSoP]<br></blockquote><div><br></div><div>=C2=A0Having a lot of setters f=
or options might make it really hard to find the methods you&#39;re looking=
 for in terms of auto-complete in your IDE. Would it make sense to split op=
tions into a separate object (or perhaps multiple), that could in theory al=
so be shared between different CurlHandle instances?</div></div></div>

--000000000000efbdab0611a99b23--