Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127216
Precedence: bulk
MIME-Version: 1.0
References: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <dd61999c-1ebd-4765-9add-cd8065968965@gmail.com> <CAOV5rgYZ_s1of-igLFEK7oqqh6=3HeYv0=JvvKvvjkcp0F6Q9Q@mail.gmail.com>
 <CAH5C8xV67frqOBCvLt73RM7QO86_pu40sHP5h71_kDRbKPtA8Q@mail.gmail.com>
 <1BCB4144-231D-45EA-A914-98EE8F0F503A@automattic.com> <8E614C9C-BA85-45D8-9A4E-A30D69981C5D@automattic.com>
 <CAH5C8xV69pHnSKWJrVB8EQab7vPhcaXAwYezoG6z3Oj7ZkXBaQ@mail.gmail.com>
 <bc5472e39bc607e2c7accc9d2bd6f239@bastelstu.be> <CAH5C8xW_auVf+ig7odhTK8dVWwmXTg4ZVZN-0Fhh4SUBzrWxVw@mail.gmail.com>
 <8df04e01-deac-404b-beb7-cd982423db63@bastelstu.be> <CAH5C8xU0JcnmC2Hdd=Hj0CQUaL0-LN=1X8+5-eUbFH3ZMxCvBA@mail.gmail.com>
 <33427cd03035ef084245c44290b56a55@bastelstu.be> <CAH5C8xXwDO6Ui8pLmqoxEguURh97fAaL4CfLK-oitqC85N7+8w@mail.gmail.com>
 <0aa1eefc3941bdea0092e935074daa58@bastelstu.be> <CAH5C8xU+rnp4e5=CzqhEncRww6nhZ7x1s68NjWtu+HQMpoNZ8g@mail.gmail.com>
 <76d96ea8a78c6025128c0a4b01c94c0a@bastelstu.be>
In-Reply-To: <76d96ea8a78c6025128c0a4b01c94c0a@bastelstu.be>
Date: Sun, 27 Apr 2025 23:47:04 +0200
Message-ID: <CAH5C8xXLPoRLJ6_dtotMtOv2NWs4LFzu+Kpr5A56Xk8wmuPDEg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c097d40633c98235"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000c097d40633c98235
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=C3=A1t=C3=A9

--000000000000c097d40633c98235
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Tim,</div><div class=3D"gmail_quote gm=
ail_quote_container"><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">
In <a href=3D"https://news-web.php.net/php.internals/127114" rel=3D"norefer=
rer" target=3D"_blank">https://news-web.php.net/php.internals/127114</a> I =
suggest to only <br>
provide the &quot;non-raw&quot; methods, so I believe you misread that. I&#=
39;ve just <br>
given the RFC another read and thought about the naming and I believe I <br=
>
still prefer not having the &quot;raw&quot; in the name:<br>
<br>
- Having the `raw` in the name makes the API very clunky / verbose to <br>
use.<br>
- Other implementations, such as in browsers or node.js, also simply use <b=
r>
the component name without any indication of the output being raw.<br>
- Future changes to the WHATWG URL specification might introduce some <br>
normalization for components that currently doesn&#39;t have normalization.=
 <br>
This would make the `raw` naming a misnomer and might require new <br>
methods / deprecations on PHP&#39;s end.<br>
<br>
So it seems to be safer to use the naming without the `raw` and then in <br=
>
the documentation explain what happens with useful examples, just like <br>
the RFC already does.<br>
<br></blockquote><div><br></div><div>We discussed this off the list, and th=
e recommendation made sense to me at last.</div><div>I described the ration=
ale in the RFC around the end of the &quot;Component retrieval&quot; / &quo=
t;Basic examples&quot; section.</div><div><br></div><div>Additionally, I re=
corded a few WHATWG related &quot;deviations&quot; from the specified gette=
r and setter steps along with</div><div>the rationale of these choices.</di=
v><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Other than that, I noticed the following small issues:<br><br></blockquote>=
<div><br></div><div>I fixed all these small errors, thanks for pointing the=
m out.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">
5.<br>
<br>
In the &quot;Serialization&quot; section: The explanation of the serializat=
ion <br>
format is overly specific regarding the implementation details. I would <br=
>
simplify that to just say &quot;it supports serialization by using the <br>
toRawString() output and performs strict checks during unserialization&quot=
; <br>
or similar. The reason is that I want to make some suggestions to the <br>
serialization format to provide greater flexibility for future changes <br>
during the technical review of the implementation :-)<br></blockquote><div>=
<br></div><div>After an off-the-list discussion, I updated the RFC text so =
that it reflects the</div><div>desired behavior (that is consistent with th=
e serialization format of ext/random).</div><div><br></div><div>Regards,</d=
iv><div>M=C3=A1t=C3=A9</div></div></div>

--000000000000c097d40633c98235--