Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126499
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\))
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
In-Reply-To: <cf16068b3acf6692172ee0971fcda417@bastelstu.be>
Date: Tue, 25 Feb 2025 06:36:20 -0600
Cc: PHP Internals List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <19377F60-FB7F-4E6E-A085-4DCB6CD92234@pmjones.io>
References: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <RYUX5rSGApW8lPGs1yovM2fIXXBHd_UcqEKAKgj8-dRrpThS4tC195Jb3kPTT5up96r7SZ2WunauAblAIEkZe41BwZxLeSE2SaKQLAYSmZo=@gpb.moe>
 <811B65CE-1DF0-4A47-937C-4FCB6E945B92@pmjones.io>
 <cf16068b3acf6692172ee0971fcda417@bastelstu.be>
To: =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>,
 "Gina P. Banyard" <internals@gpb.moe>
From: pmjones@pmjones.io (Paul M . Jones)

Hi there,

> On Feb 24, 2025, at 03:36, Tim D=C3=BCsterhus <tim@bastelstu.be> =
wrote:
>=20
...
>=20
> but had a look at the =E2=80=9Cafter-action summary=E2=80=9D thread =
and specifically C=C3=B4me=E2=80=99s response, which you apparently =
agreed with:
>=20
>> My take on that is more that functionality in core needs to be =
=C2=ABperfect=C2=BB, or at least near unanimous.

C=C3=B4me Chilliet's full quote goes on to say "And of course it=E2=80=99s=
 way easier to find a solution which pleases everyone when it=E2=80=99s =
for something quite simple" -- the example was of `str_contains()`.


> Or perhaps phrased differently, like I did just a few days ago in: =
https://externals.io/message/126350#126355
>=20
>> The type of functionality that is nowadays added to PHP=E2=80=99s =
standard library is =E2=80=9Cbuilding block=E2=80=9D functionality: =
Functions that a userland developer would commonly need in their custom =
library or application.
>=20

> *Correctly* processing URIs is a common need for developers and it=E2=80=
=99s complicated to do right, thus it qualifies as a =E2=80=9Cbuilding =
block=E2=80=9D.

Agreed. Add to that:


> On Feb 23, 2025, at 18:48, Gina P. Banyard <internals@gpb.moe> wrote:
>=20
> Considering that one of the other stated goals of this RFC is to =
provide this API to other core extensions, the previous objections do =
not apply here.

(The previous objections being that this ought to be left in userland.)

* * *

I'm repeatedly on record as saying that PHP, as a web-centric language, =
ought to have more web-centric objects available in core. A _Request_ =
would be one of those; a _Response_ another; and as being discussed =
here, a _Url_.

However, if it is true that ...

- "it=E2=80=99s way easier to find a solution which pleases everyone =
when it=E2=80=99s for something quite simple"

- "The type of functionality that is nowadays added to PHP=E2=80=99s =
standard library is =E2=80=9Cbuilding block=E2=80=9D functionality: =
Functions that a userland developer would commonly need in their custom =
library or application."

- "one of the other stated goals of this RFC is to provide this API to =
other core extensions"

- "Parsing is the single most important operation to use with URIs where =
a URI string is decomposed into multiple components during the process." =
(from the RFC)

... then an extensive set of objects and exceptions is not strictly =
necessary.

Something like `function parse_url_whatwg(string $url_string, ?string =
$base_url =3D null) : array`, with an array of returned components, =
would meet all of those needs.

Similarly, something like a `function parse_url_rfc3986(string =
$uri_string, ?string $base_url =3D null) : array` does the same for RFC =
3986 parsing.

Those things combined provide solid parsing functionality to userland, =
and make that parsing functionality available to other core extensions.


-- pmj