> On Feb 25, 2025, at 09:55, ignace nyamagana butera <nyamsp...@gmail.com> 
> wrote:
> 
> 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).

The two functions need not return an identical array of components; e.g., the 
3986 parsing function might return an array much like parse_url() does now, and 
the WHATWG function might return a completely different array of components 
(one that includes the normalized and/or raw components).

All of this is to say that the parsing functionality does not have to be in an 
object to be useful *both* to the internal API *and* to userland.

Recall that I'm responding at least in part to the comment that "Considering 
that one of the other stated goals of this RFC is to provide this API to other 
core extensions, the previous objections [to the Request/Response objects going 
into core] do not apply here." If the only reason they don't apply is that the 
core extensions need a parsing API, that reason becomes obviated by using just 
functions for the parsing elements.

Unless I'm missing something; happy to hear what that might be.


-- pmj

Reply via email to