Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118191
MIME-Version: 1.0
References: <CAOfKkdR0cab4-rWdVpzGPtg8nraNBWLN3whe9xs2mAw5x1MVyw@mail.gmail.com>
In-Reply-To: <CAOfKkdR0cab4-rWdVpzGPtg8nraNBWLN3whe9xs2mAw5x1MVyw@mail.gmail.com>
Date: Tue, 5 Jul 2022 09:25:04 +0200
Message-ID: <CAOWwgpkBiWf-0_HcLchfbT5v4E8X_rC+7Ei-Aa0Q0Sc6Qhw-9Q@mail.gmail.com>
To: Pierrick Charron <pierrick@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f8aba105e309c037"
Subject: Re: [PHP-DEV] [RFC][Vote] New Curl URL API
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000f8aba105e309c037
Content-Type: text/plain; charset="UTF-8"

> 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
> implementation that stays consistent with other functions of the ext/curl
> to target 8.2.


I fully support this approach: php-src is not the proper layer to build an
OOP API to me. Each time it's been done, it proved too rigid for userland
and ppl wrote wrappers around.

I think php-src should continue to provide thin layers on top of C
libraries so that userland is then empowered to build and evolve OOP APIs
at will.

Nicolas

--000000000000f8aba105e309c037--