Re: [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace & Maté & all, > On Mar 19, 2025, at 16:18, Ignace Nyamagana Butera <nyamsprod@gmail.com> 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