Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127762
Precedence: bulk
MIME-Version: 1.0
References: <CA+NMNO0K85acCismdBL=8vr5=nKg1_-i0BjXyiqnjoqGAnH3Xw@mail.gmail.com>
 <22a4327d-b27d-4e24-b07a-ae380fe8a0c4@app.fastmail.com>
In-Reply-To: <22a4327d-b27d-4e24-b07a-ae380fe8a0c4@app.fastmail.com>
Reply-To: erictnorris@gmail.com
Date: Thu, 26 Jun 2025 13:54:00 -0400
Message-ID: <CA+NMNO1Nkmzhn-8a5aONpyaJ1tVPGCMP+37UJbX2p7K=WDPxXg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
From: eric.t.norris@gmail.com (Eric Norris)

Thanks Larry!

> 1. I don't think the Curl\Option namespace is necessary.  They can just be in the main Curl namespace.

I don't feel strongly here, but I thought it would be nice to group
the enums (if we go the multiple enum route) for discoverability.
Thoughts?

> 2. Please don't name the exception "Exception".  It needs some slightly more useful name, to avoid confusion in a file that also uses \Exception.

Fair point! I could use the previous RFC's HandleException class name,
barring your next point...

> 3. I realize `Handle` is the name from the procedural API, but it's not very self-descriptive.  Without knowing Curl, it's non-obvious that it's a self-executing request object.  Is there a better name we could find while we're at it?

I'm open to this, but I don't have a suggestion myself.

> 4. Love the use of aviz. :-)

Thanks :) I was happy to be able to use it here.

> 5. Now here's the big one: Using enums rather than a bunch of constants is a good change.  However, I feel like it doesn't go far enough.
> ...
> As a worst case, perhaps the top-20 options or so could be converted to methods/properties, and the rest left to be ugly flags?

I think my hesitation here is related to Ben's sibling response: I
want to thread the needle between making small improvements to the
low-level API while translating them to object-oriented equivalents,
and making a high-level API. The latter, I think, would invite a lot
more discussion, and would be potentially hard to get right.

That said, maybe your suggestion does thread that needle; having a
method / property for the N most-used options is still relatively
low-level since it's not expressing an opinion on how they should be
used. I'm not sure.