Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118078
Date: Thu, 23 Jun 2022 21:04:35 +0100
CC: PHP internals <internals@lists.php.net>
User-Agent: K-9 Mail for Android
In-Reply-To: <CAAKU0um7-7KZnBibwQxkvm_Kq8a264BZYOPc8G2jfax_43odjQ@mail.gmail.com>
References: <CAOfKkdTjPiZHnSHuag_+fmFK-1Advh2-vfDgbJBXEmK=72NB0g@mail.gmail.com> <CAAKU0um7-7KZnBibwQxkvm_Kq8a264BZYOPc8G2jfax_43odjQ@mail.gmail.com>
Message-ID: <56F11D5A-7E07-4CE7-99CE-62D342834667@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API
From: rowan.collins@gmail.com (Rowan Tommins)

On 23 June 2022 17:48:57 BST, Levi Morrison via internals <internals@lists=
=2Ephp=2Enet> wrote:
>IMO, this should mirror the low-level curl url API very directly=2E The
>basis of my opinion is that we do not own libcurl; we are merely
>adapting it for use in PHP=2E We cannot anticipate changes in their
>design, nor do we have authority to do so if we feel something should
>change=2E Touching it as little as possible makes it easier to track
>upstream changes, etc=2E
>
>Based on that, I think the naming should be closer to libcurl=2E:
>  - CurlUrl::URL_ENCODE should be CurlUrl::URLENCODE
>  - CurlUrl::URL_DECODE should be CurlUrl::URLDECODE
>
>And so on, only differing if necessary because something is a reserved
>word=2E The API should be as exact as possible to what libcurl provides=
=2E
>The "helpers" getHost, getPassword, etc should be removed and should
>expose `curl_url_get` more directly=2E
>
>Of course, it should be object based instead of resource based, but that'=
s it=2E
>
>A nicer API can be built on top of it, but I don't think that's the
>role this particular API should play=2E


For the record, I disagree with literally everything you've said here=2E

PHP indeed does not own libcurl, and nor does libcurl own PHP=2E We are ta=
rgeting a different audience, and have a different set of facilities availa=
ble to us=2E We have our own documentation, so there is no reason a user of=
 PHP should know or care what the underlying implementation looks like, any=
 more than they should know how the memory allocation works=2E

If the underlying library adds a feature, it will be as easy to add a new =
method as a new constant=2E If the underlying library changes behaviour, we=
 will want to make our own decision on whether that meets our compatibility=
 policy, and whether to emulate the older behaviour (or indeed emulate the =
newer behaviour on systems with an older library)=2E

Twenty years ago, maybe PHP programmers were used to it being a veneer ove=
r C=2E I don't think that is or should be the expectation today, unless you=
're using FFI=2E

Regards,

--=20
Rowan Tommins
[IMSoP]