Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122433
Date: Sun, 18 Feb 2024 22:05:56 +0000
CC: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [RFC] OOP API for cURL extension
User-Agent: K-9 Mail for Android
In-Reply-To: <CANS-=pdZsR2y-2Z+cHVLFv=h2s+OBvJTn5LULUjOE05AR0i2xg@mail.gmail.com>
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> <CANS-=pdZsR2y-2Z+cHVLFv=h2s+OBvJTn5LULUjOE05AR0i2xg@mail.gmail.com>
Message-ID: <C6D426F6-8428-4673-B36F-A082C6D092D3@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: rowan.collins@gmail.com (Rowan Tommins)

On 18 February 2024 15:26:37 GMT, Lynn <kjarli@gmail=2Ecom> wrote:
> Having a lot of setters for options might make it really hard to find th=
e
>methods you're looking for in terms of auto-complete in your IDE=2E=20


I think it would be significantly better for that purpose than what we hav=
e now, because there would be a lot fewer methods than there are current op=
tion constants=2E=20

Firstly, because most of the methods would cover multiple overlapping or r=
elated options - e=2Eg=2E setHttpMethod(string $method) covers CURLOPT_POST=
, CURLOPT_PUT, CURLOPT_CUSTOMREQUEST, and CURLOPT_HTTPGET; setBasicAuth($us=
ername, $password) combines CURLOPT_HTTPAUTH, CURLOPT_USERNAME, and CURLOPT=
_PASSWORD=2E

Secondly, because some functionality that's not used as often can just be =
left to the curl_setopt equivalents forever, e=2Eg=2E we don't need new met=
hods for CURLOPT_DNS_SHUFFLE_ADDRESSES, CURLOPT_HAPPY_EYEBALLS_TIMEOUT_MS, =
etc, etc=2E

The initial aim could be to cover, say, the 10 most commonly used settings=
 - things like choosing the request method, and including custom request he=
aders=2E Over time, we could add more methods for common tasks, but continu=
e adding constants / enum cases for more obscure features of the library=2E


> Would it
>make sense to split options into a separate object (or perhaps multiple),
>that could in theory also be shared between different CurlHandle instance=
s?

While I'm not against splitting things up into more objects, I think that =
becomes a much bigger task to define what goes in each, and harder to do ha=
lf-way=2E My gut feeling is that it would descend into a lot of bikesheddin=
g, and stop us making progress; whereas adding a few methods for common use=
 cases could present a real quick win=2E


Regards,

--=20
Rowan Tommins
[IMSoP]