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

From: Date: Sun, 27 Apr 2025 21:47:04 +0000
Subject: Re: [RFC] [Discussion] Add WHATWG compliant URL parsing API
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
Hi Tim,


> In https://news-web.php.net/php.internals/127114
> I suggest to only
> provide the "non-raw" methods, so I believe you misread that. I've just
> given the RFC another read and thought about the naming and I believe I
> still prefer not having the "raw" in the name:
>
> - Having the raw in the name makes the API very clunky / verbose to
> use.
> - Other implementations, such as in browsers or node.js, also simply use
> the component name without any indication of the output being raw.
> - Future changes to the WHATWG URL specification might introduce some
> normalization for components that currently doesn't have normalization.
> This would make the raw naming a misnomer and might require new
> methods / deprecations on PHP's end.
>
> So it seems to be safer to use the naming without the raw and then in
> the documentation explain what happens with useful examples, just like
> the RFC already does.
>
>
We discussed this off the list, and the recommendation made sense to me at
last.
I described the rationale in the RFC around the end of the "Component
retrieval" / "Basic examples" section.

Additionally, I recorded a few WHATWG related "deviations" from the
specified getter and setter steps along with
the rationale of these choices.

Other than that, I noticed the following small issues:
>
>
I fixed all these small errors, thanks for pointing them out.


> 5.
>
> In the "Serialization" section: The explanation of the serialization
> format is overly specific regarding the implementation details. I would
> simplify that to just say "it supports serialization by using the
> toRawString() output and performs strict checks during unserialization"
> or similar. The reason is that I want to make some suggestions to the
> serialization format to provide greater flexibility for future changes
> during the technical review of the implementation :-)
>

After an off-the-list discussion, I updated the RFC text so that it
reflects the
desired behavior (that is consistent with the serialization format of
ext/random).

Regards,
Máté


Thread (152 messages)

« previous php.internals (#127216) next »