Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126906
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: <2e95e8fe-7cf0-493f-bd0a-9fff0956baaa@gmail.com>
Date: Sat, 22 Mar 2025 09:01:45 -0500
Cc: =?utf-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>,
 PHP Internals List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <778194E9-679B-4178-94F8-052FB2C4DA37@pmjones.io>
References: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <dd61999c-1ebd-4765-9add-cd8065968965@gmail.com>
 <CAOV5rgYZ_s1of-igLFEK7oqqh6=3HeYv0=JvvKvvjkcp0F6Q9Q@mail.gmail.com>
 <CAH5C8xV67frqOBCvLt73RM7QO86_pu40sHP5h71_kDRbKPtA8Q@mail.gmail.com>
 <1BCB4144-231D-45EA-A914-98EE8F0F503A@automattic.com>
 <8E614C9C-BA85-45D8-9A4E-A30D69981C5D@automattic.com>
 <CAH5C8xV69pHnSKWJrVB8EQab7vPhcaXAwYezoG6z3Oj7ZkXBaQ@mail.gmail.com>
 <bc5472e39bc607e2c7accc9d2bd6f239@bastelstu.be>
 <9bf11a89-39d9-457b-b0ea-789fd07d7370@gmail.com>
 <CAH5C8xWnoytE=jm1sxr-HcSZFzmG8SrzghinmBZa-QyGqN4uUg@mail.gmail.com>
 <6430b9ed-638d-4247-9fa9-d1a9148c382b@gmail.com>
 <CAH5C8xX3tCS3B3z2YFbRudCXi=ZNHE0scrmoFO7cXxU773EfpA@mail.gmail.com>
 <2e95e8fe-7cf0-493f-bd0a-9fff0956baaa@gmail.com>
To: Ignace Nyamagana Butera <nyamsprod@gmail.com>
From: pmjones@pmjones.io ("Paul M. Jones")

Hi Ignace & Mat=C3=A9 & all,

> On Mar 19, 2025, at 16:18, Ignace Nyamagana Butera =
<nyamsprod@gmail.com> wrote:
>=20
> https://github.com/bakame-php/aide-uri/blob/main/src/Uri.php=20
> While implementing the polyfill I am finding easier DX wise to make =
the constructor private and use instead named constructors for =
instantiation. I would be in favor of  `Uri::parse` and `Uri::tryParse` =
like it is done currently with Enum and the `from` and `tryfrom` named =
constructors.

Hear, hear. Uri-Interop <https://github.com/uri-interop/interface> has =
discovered two interfaces in existing projects:

- one method with a `parseUri(stringStringable $uriString) : =
UriComponents` signature to parse a string and create a URI instance; =
and,

- a separate method with a `newUri(?string $scheme, ?string $username, =
..., ?string $fragment) : UriComponents` signature that creates a URI =
instance from the individual components.

Neither of them dictates a constructor signature, but having the parser =
method separated from the factory method turns out to be quite useful. =
Presenting the two options as separate methods would reflect existing =
implementations.

* * *

As a side note, the RFC uses the term `user` for the identifying part of =
the user info. It's perfectly reasonable, as `user` is the =
most-commonly-used term in existing URI projects. =
<https://github.com/uri-interop/interface/blob/1.x/README-RESEARCH.md#user=
username>

However, WHATWG-URL consistently calls it `username`, putting the URL =
portion of the RFC at odds with the WHATWG-URL spec. Calling it =
`username` would be more in line with the spec. That would likely mean =
calling it `username` in the URI portion of the RFC as well. =
(Uri-Interop reviewers found `username` more suitable as well. =
<https://github.com/uri-interop/interface?tab=3Dreadme-ov-file#why-usernam=
e-and-not-user>)


-- pmj