Hi,
On Thu, 27 Feb 2025, 20:55 Paul M. Jones, <pmjo...@pmjones.io> wrote: > > > 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. > It most definitely needs to be an object. Arrays are awful DX wise, there is array shape which modern IDEs like phpstorm support and so does static analysis but the overall experience remains subpar compared to classes (and objects). > 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 > Imho Request and Response objects do belong in core, but with a very good api, something which would replace http foundation/PSR7 altogether. >
