On 22 March 2025 16:08:54 GMT, "Paul M. Jones" <pmjo...@pmjones.io> wrote:
>Next up: what exactly should the API around this functionality look like? I
>suggested functions but that's clearly a non-starter; what do we feel is a
>good alternative, and can it be achieved independently from (but in support
>of) the URI+WHATWG-URL proposal?
As I say, I haven't followed the previous conversation at all, but from a
glance at the RFC, it seems the proposed classes are called "Url"/"Uri", not
"UrlParser"/"UriParser", so could maybe be expanded to creating *from* parts. I
don't know where exactly IRIs should fit in, but maybe as a new object in the
same hierarchy?
There's also definitely a place for standalone functions for handling specific
jobs on fragments of URIs. It would actually be really great to have a
replacement for parse_str which didn't carry the baggage of old PHP versions -
no by-reference output, no name mangling of keys (at least not by default).
http_build_query isn't as urgently in need of replacement, but a clean start
could default the separator to '&' rather than pulling from an INI setting.
Whether each function should take an enum flag for encoding variants, or be
split into a family of similar functions, I don't know. At the moment,
http_build_query accepts constants, (raw)urlencode is split into two functions,
and parse_str doesn't give any option.
I don't want to have to memorise a bunch of RFC numbers in order to know
whether spaces will be encoded as plus signs, but maybe we can find something
more descriptive than "raw" to distinguish them.
In short, I wouldn't start from the point of "how do we extend current
functions to handle IRIs?", I'd start from the point of "what functions do we
need for handling URI/URL/IRI parts, and what variations of each?"
Rowan Tommins
[IMSoP]
