> Hello Internals,
>
> I'd like to formally propose a restart of the original object-oriented
> curl API RFC (https://wiki.php.net/rfc/curl-oop):
>
> https://wiki.php.net/rfc/curl_oop_v2
>
> The prior RFC seemed to get positive feedback, with a small consensus
> around wanting enum(s) for curl opti
Le sam. 28 juin 2025 à 00:01, Ayesh Karunaratne a écrit :
> > Hello Internals,
> >
> > I'd like to formally propose a restart of the original object-oriented
> > curl API RFC (https://wiki.php.net/rfc/curl-oop):
> >
> > https://wiki.php.net/rfc/curl_oop_v2
> >
> > The prior RFC seemed to get posi
> I'm not even sure it's a good idea to add those namespaced options: using
> CURLOPT_SSL_VERIFYHOST is perfect to find the corresponding curl
> documentation with your favorite search engine. php's doc is awesome, but it
> cannot compete with the details provided by curl's doc on the topic.
>
>
On Fri, Jun 27, 2025, at 4:58 PM, Ayesh Karunaratne wrote:
> However, I softly oppose this RFC in its current state and the way it
> seems to be going.
So I think we've identified a key disagreement about not just the goal, but the
intent. To what extent should PHP core ship with a usable HTTP
Hi folks. Arnaud and I would like to present take-2 at Partial Function
Application.
https://wiki.php.net/rfc/partial_function_application_v2
It is largely similar to the previous PFA proposal from 2021, though there are
a number of changes. Most notably:
* The implementation is simpler, bec
On Fri, Jun 27, 2025, at 8:01 AM, Deleu wrote:
> On Fri, Jun 27, 2025 at 9:24 AM Jordi Boggiano wrote:
>> On 26.06.2025 18:25, Eric Norris wrote:
>> > - uses enumerations for curl options and other curl constants
>>
>> Overall I think the RFC is a good opportunity to clean up a few legacy
>> odd
On Thu, Jun 26, 2025, at 10:51 PM, Eric Norris wrote:
>> Adding more helpers in later versions is entirely trivial, but we could
>> set the precedent with a first batch on day one.
>
> I'm not opposed to this, but I am - as previously stated - nervous
> about how and where we draw this line, since
On 6/27/25 08:01, Deleu wrote:
With that said, for me this also threads into the bikeshedding area
that could spiral into a failed RFC. Be it a single Enum for
everything, constants, context-based enums or type-based enums, I
would much rather have this RFC than not have it. PHP is one of the
On 26.06.2025 18:25, Eric Norris wrote:
- uses enumerations for curl options and other curl constants
Overall I think the RFC is a good opportunity to clean up a few legacy
oddities in the curl API, but I need to throw in my 2c about enum usage
here, as someone that has actually implemented s
> When `BcMath\Number` was introduced it allowed `string|int` method
> arguments. According to a separate RFC to allow `int` to the functions this
> was done as a performance optimization. Unfortunately this also means it
> effectively disallows `float` types because PHP will truncate them to
On Fri, Jun 27, 2025 at 9:24 AM Jordi Boggiano wrote:
> On 26.06.2025 18:25, Eric Norris wrote:
> > - uses enumerations for curl options and other curl constants
>
> Overall I think the RFC is a good opportunity to clean up a few legacy
> oddities in the curl API, but I need to throw in my 2c abo
On 27/06/2025 04:51, Eric Norris wrote:
I can try to take a look at the curl options and do some github
searches to see if I can identify common patterns. I agree that
setting the HTTP method and timeout are good contenders. If someone
else wants to propose a list as well, feel free!
For what
-Original Message-
From: Eric Norris
Sent: Thursday, June 26, 2025 7:25 PM
To: PHP internals
Subject: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2
> I'd like to formally propose a restart of the original object-oriented curl
> API RFC
Cool. Calling functions with object as
Hi all,
> On 26/06/2025 18:21, Eric Norris wrote:
>> I know that in the prior discussion, Rowan Tommins had a vision for a
>> high-level API (https://externals.io/message/122371#122424)
>
>
> I think calling it a "vision for a high-level API" is making it sound far
> more grandiose than what I
14 matches
Mail list logo
