Hi Ignace & Maté & all,
> On Mar 19, 2025, at 16:18, Ignace Nyamagana Butera <[email protected]> wrote:
>
> https://github.com/bakame-php/aide-uri/blob/main/src/Uri.php
>
> 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#userusername>
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=readme-ov-file#why-username-and-not-user>)
-- pmj