On Fri, 28 Jun 2024, at 21:06, Máté Kocsis wrote:
> […] add a WHATWG compliant URL parser functionality to the standard library. The API itself
> is not final by any means, the RFC only represents how I imagined it first.
>
> You can find the RFC at the following link: https://wiki.php.net/rfc/url_parsing_api
First-pass comments/thoughts.
As others have mentioned, it seems the class would/could not actually satisfy PSR-7. Realistically,
the PSR-7 interface package or someone else would need to create a new class that combines the two,
potentially as part of a transition away from it to the built-in class, with future PSRs building
directly on Url. If we take that as given, we might as well design for the end state, and accept
that there will be a (minimal) transition. This end state would benefit from being designed with the
logical constraints of PSR-7 (so that migration is possible without major surprises), but without
restricting us to its exact API shape, since an intermediary class would come into existence either
way.
For example, Url could be a value class with merely 8 public properties. Possibly with a
UrlImmutable subclass, akin to DateTime, where the properties are read-only instead a clone method
could return Url?).
It might be more ergonomic to leave the parser as implementation detail, allowing the API to be
accessed from a single import rather than requiring two. This could look like Url::parse() or
Url::parseFromString().
For the Url::parseComponent() method, did you consider accepting the existing PHP_URL_* constants?
They appear to fit exactly, in naming, description, and associated return types.
Without UrlParser/UrlComponent, I'd adopt it direclty in applications and frameworks. WIthout
it, further wrapping seems likely for improved usability. This is sometimes benefitial when exposing
low-level APIs, but it seems like this is close to fitting in a single class, as demonstrated by the
WHATWG URL API.
One thing I feel is missing, is a method to parse a (partial) URL relative to another. E.g. to
expand or translate paths between two URLs. Consider expanding "/w/index.php", or
"index.php" relative to "https://wikipedia.org/w/". Or expanding
"//example.org" relative to either "https://wikipedia.org" vs "http://wikipedia.org". The WHATWG URL API does this in
the form of a second optional string|Stringable parameter to Url::parse(). Implementing "expand
URL" with parsing of incomplete URLs is error-prone and hard to get right. Including this
would be valuable.
See also Net_URL2 and its resolve() method https://pear.php.net/package/Net_URL2
https://github.com/pear/Net_URL2
--
Timo Tijhof
https://timotijhof.net/