Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127771
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 27 Jun 2025 09:29:27 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <defa5ac4-37e9-4e65-a190-9536602101f1@app.fastmail.com>
In-Reply-To: 
 <CADK1yXK=pV3D5Upe0Nnt_aYTwGe4iB4QdF56Vx5TDQLc97fD=A@mail.gmail.com>
References: 
 <CA+NMNO0K85acCismdBL=8vr5=nKg1_-i0BjXyiqnjoqGAnH3Xw@mail.gmail.com>
 <e52fa8b0-31c7-4280-9d6f-8cb5578a4dce@seld.be>
 <CADK1yXK=pV3D5Upe0Nnt_aYTwGe4iB4QdF56Vx5TDQLc97fD=A@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Jun 27, 2025, at 8:01 AM, Deleu wrote:
> On Fri, Jun 27, 2025 at 9:24=E2=80=AFAM Jordi Boggiano <j.boggiano@sel=
d.be> wrote:
>> On 26.06.2025 18:25, Eric Norris wrote:
>> > - uses enumerations for curl options and other curl constants
>>=20
>> Overall I think the RFC is a good opportunity to clean up a few legac=
y=20
>> oddities in the curl API, but I need to throw in my 2c about enum usa=
ge=20
>> here, as someone that has actually implemented some complexish=20
>> curl-based client [1].
>>=20
>> Currently the API is:
>>=20
>>      curl_setopt($h, CURLOPT_SMTH, 3);
>>=20
>> Now moving this into multiple enums to me brings one major issue, tha=
t I=20
>> first have to think about which type the option has to then know on=20
>> which enum I find it.
>>=20
>> I understand this brings type safety on the value side if you have=20
>> multiple setOptionInt etc, but that does not seem worth the trade-off=
 to=20
>> me. Type safety can already be done in static analyzers as they can s=
ee=20
>> which option you pass in, they know which value should be allowed.
>>=20
>> Then on top of that, assuming we'd put all options in one enum.. I am=20
>> still wondering what the added value is compared to simply having the=20
>> global constants (they could be namespaced if anything...). It's long=
er=20
>> to type, and does not provide any better autocompletion.=20
>> \Curl\Option::ConnectTimeout vs CURLOPT_CONNECT_TIMEOUT sounds ok to =
me=20
>> if people feel strongly pro-enum, but I do really hope it is then a=20
>> single enum + setOption() call.
>>=20
>> Best,
>> Jordi
>>=20
>> [1]=20
>> https://github.com/composer/composer/blob/main/src/Composer/Util/Http=
/CurlDownloader.php
>>=20
>> Jordi Boggiano
>> @seldaek - https://seld.be
>
> Reading this I can't help but feel like there's some cognitive bias=20
> *because* you have written a Curl class yourself. The author of a PHP=20
> Class that wraps Curl needs to know about every option and how to=20
> translate them back-and-forth, which is really the insight I take from=20
> your message. As a PHP developer making HTTP requests, I would never=20
> have guessed 270 options for Curl configurations and having them split=20
> into multiple Enums gives me smaller "boxes" that are easier to=20
> mentally parse individually. With that said, splitting enumerations by=20
> type rather than context does weaken the argument of split enums. I=20
> wouldn't be instinctively looking for "what enum do I need that is an=20
> int?" or "what enum do I need that is a string?" unless I already know=20
> the implementation details by heart. The Info and Pause enumerations=20
> seem more useful in that regard as they reduce the scope in which I=20
> need to understand, process and decide.=20

I will agree here.  Splitting enums by type doesn't add much value.  Spl=
itting them by topic might, if the topics are sufficiently distinct that=
 a separate method makes sense.  I don't know Curl's API well enough to =
make specific recommendations there.

--Larry Garfield