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