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

On 25/02/2025 13:36, Paul M.Jones wrote:

Hi there,

On Feb 24, 2025, at 03:36, Tim Düsterhus <tim@bastelstu.be> wrote:

...

but had a look at the “after-action summary” thread and specifically Côme’s response, which you apparently agreed with:

My take on that is more that functionality in core needs to be «perfect», or at least near unanimous.

Côme Chilliet's full quote goes on to say "And of course it’s way easier to find a solution which pleases everyone when it’s for something quite simple" -- the example was of str_contains().

Or perhaps phrased differently, like I did just a few days ago in: https://externals.io/message/126350#126355

The type of functionality that is nowadays added to PHP’s standard library is “building block” functionality: Functions that a userland developer would commonly need in their custom library or application.

*Correctly* processing URIs is a common need for developers and it’s complicated to do right, thus it qualifies as a “building block”.

Agreed. Add to that:

On Feb 23, 2025, at 18:48, Gina P. Banyard <internals@gpb.moe> wrote: Considering that one of the other stated goals of this RFC is to provide this API to other core extensions, the previous objections do not apply here.

(The previous objections being that this ought to be left in userland.) * * * I'm repeatedly on record as saying that PHP, as a web-centric language, ought to have more web-centric objects available in core. A _Request_ would be one of those; a _Response_ another; and as being discussed here, a _Url_. However, if it is true that ... - "it’s way easier to find a solution which pleases everyone when it’s for something quite simple" - "The type of functionality that is nowadays added to PHP’s standard library is “building block” functionality: Functions that a userland developer would commonly need in their custom library or application." - "one of the other stated goals of this RFC is to provide this API to other core extensions" - "Parsing is the single most important operation to use with URIs where a URI string is decomposed into multiple components during the process." (from the RFC) ... then an extensive set of objects and exceptions is not strictly necessary. Something like function parse_url_whatwg(string $url_string, ?string $base_url = null) : array, with an array of returned components, would meet all of those needs. Similarly, something like a function parse_url_rfc3986(string $uri_string, ?string $base_url = null) : array does the same for RFC 3986 parsing. Those things combined provide solid parsing functionality to userland, and make that parsing functionality available to other core extensions. -- pmj

Hi Paul, The problem with your suggestion is that the specification from WHATWG and RFC3986/3987 are so different and that the function you are proposing won't be able to cover the outcome correctly (ie give the developper all the needed information). This is why, for instance, Maté added the getRaw* method alongside the normalized getter (method without the Raw prefix). Also keep in mind that URL construction may also differ between specifications so instead of just 2 functions you may end up woth 4 methods not counting error jandling. So indeed using an OOP approach while more complex is IMHO the better approach.