On 05/07/2022 00:34, Pierrick Charron wrote:
I opened voting for the new Curl URL API as part of PHP8.2.
https://wiki.php.net/rfc/curl-url-api
All recent discussions show that we are not even close to getting a
consensus on how the new CurlUrl OO API should be done. After changing my
mind 300 ti
> Hi internals,
>
> I opened voting for the new Curl URL API as part of PHP8.2.
>
> All recent discussions show that we are not even close to getting a
> consensus on how the new CurlUrl OO API should be done. After changing my
> mind 300 times in the last day, I decided to only propose the procedu
Sorry about that
const CURLUPART_USER = UNKNOWN; // what UNKNOWN?
>
UNKNOWN means that the value here is not relevant for the user to know. But
for clarification, the values of those constants will be the exact same
values of the same constants in libcurl.
"All errors of libcurl will become Curl
Clear "no" from me on this: this is something similar to a PSR-7 URI
object, but with a clunky and mutable API.
Something like this would/should go to packagist first, to assess adoption
there, but I would certainly not use it.
On Tue, 5 Jul 2022, 01:34 Pierrick Charron, wrote:
> Hi internals,
On 05.07.2022 01:34, Pierrick Charron wrote:
Hi internals,
I opened voting for the new Curl URL API as part of PHP8.2.
I found some not clear fragments in the RFC.
const CURLUPART_USER = UNKNOWN; // what UNKNOWN?
"All errors of libcurl will become CurlUrlException."
"Setting a part to a nul
Hi internals,
I opened voting for the new Curl URL API as part of PHP8.2.
All recent discussions show that we are not even close to getting a
consensus on how the new CurlUrl OO API should be done. After changing my
mind 300 times in the last day, I decided to only propose the procedural
implemen
