On Fri, Feb 28, 2025 at 12:05 AM Rob Landers <rob@bottled.codes> wrote:
> > > On Thu, Feb 27, 2025, at 22:01, Faizan Akram Dar wrote: > > 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). > > > I’m curious why you say this other than an opinion about developer > experience? Arrays are values, objects are not. A parsed uri seems more > like a value and less like an object. Just reading through the comments so > far, it appears that whatever is used will just be wrapped in library code > regardless, for userland code, but the objective is to be useful for other > extensions and core code. In that case, a hashmap is much easier to work > with than a class. > > Looking at the objectives of the RFC and the comments here, it almost > sounds like it is begging to be a simple array instead of an object. > > — Rob > Depends on there being the intention to have it as parameter type. If it's designed to be passed around to functions I really don't want it to be an array. I am maintaining a legacy codebase where arrays are being used as hashmaps pretty much everywhere, and it's error prone. We lose all kinds of features like "find usages" and refactoring key/property names. Silly typos in array keys with no actual validation of any kind cause null values and annoying to find bugs. I agree that hashmaps can be really easy to use, but not as data structures outside of the function/method scope they were defined in. If value vs object semantics are important here, then something that is forward compatible with whatever structs may hold in the future could be interesting.
