On Thu, Feb 27, 2025, at 22:01, Faizan Akram Dar wrote:
> Hi,
>
>
> On Thu, 27 Feb 2025, 20:55 Paul M. Jones, <[email protected]> wrote:
>>
>> > On Feb 25, 2025, at 09:55, ignace nyamagana butera <[email protected]> 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