Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126521
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 28 Feb 2025 00:02:05 +0100
To: "Faizan Akram Dar" <hello@faizanakram.me>,
 "Paul M. Jones" <pmjones@pmjones.io>
Cc: "ignace nyamagana butera" <nyamsprod@gmail.com>,
 =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>,
 "Gina P. Banyard" <internals@gpb.moe>,
 "PHP Internals List" <internals@lists.php.net>
Message-ID: <93898e96-bbd6-4c2e-a1ad-35499bb2510d@app.fastmail.com>
In-Reply-To: 
 <CAMkukMw4V0YopJZbapczApH1h5ssKh_5yCEh5KCHSnDGiwTKzw@mail.gmail.com>
References: 
 <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <RYUX5rSGApW8lPGs1yovM2fIXXBHd_UcqEKAKgj8-dRrpThS4tC195Jb3kPTT5up96r7SZ2WunauAblAIEkZe41BwZxLeSE2SaKQLAYSmZo=@gpb.moe>
 <811B65CE-1DF0-4A47-937C-4FCB6E945B92@pmjones.io>
 <cf16068b3acf6692172ee0971fcda417@bastelstu.be>
 <19377F60-FB7F-4E6E-A085-4DCB6CD92234@pmjones.io>
 <da26554a-ed39-4e80-bcb4-29a46d9fdb61@gmail.com>
 <7B7987C6-37F3-432A-8BA2-9D93F428FAD5@pmjones.io>
 <CAMkukMw4V0YopJZbapczApH1h5ssKh_5yCEh5KCHSnDGiwTKzw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
Content-Type: multipart/alternative;
 boundary=15b8458da7fb44a685d8aca4be01c2a8
From: rob@bottled.codes ("Rob Landers")

--15b8458da7fb44a685d8aca4be01c2a8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Thu, Feb 27, 2025, at 22:01, Faizan Akram Dar wrote:
> Hi,
>=20
>=20
> On Thu, 27 Feb 2025, 20:55 Paul M. Jones, <pmjones@pmjones.io> wrote:
>>=20
>> > On Feb 25, 2025, at 09:55, ignace nyamagana butera <nyamsprod@gmail=
.com> wrote:
>> >=20
>> > The problem with your suggestion is that the specification from WHA=
TWG and RFC3986/3987 are so different and that the function you are prop=
osing won't be able to cover the outcome correctly (ie give the developp=
er all the needed information). This is why, for instance, Mat=C3=A9 add=
ed the getRaw* method alongside the normalized getter (method without th=
e Raw prefix).
>>=20
>> 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 compon=
ents).
>>=20
>> 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 userla=
nd.
>=20
>=20
>>=20
>=20
> It most definitely needs to be an object. Arrays are awful DX wise, th=
ere is array shape which modern IDEs like phpstorm support and so does s=
tatic analysis but the overall experience remains subpar compared to cla=
sses (and objects).=20

I=E2=80=99m curious why you say this other than an opinion about develop=
er experience? Arrays are values, objects are not. A parsed uri seems mo=
re like a value and less like an object. Just reading through the commen=
ts so far, it appears that whatever is used will just be wrapped in libr=
ary code regardless, for userland code, but the objective is to be usefu=
l for other extensions and core code. In that case, a hashmap is much ea=
sier to work with than a class.

Looking at the objectives of the RFC and the comments here, it almost so=
unds like it is begging to be a simple array instead of an object.=20

=E2=80=94 Rob
--15b8458da7fb44a685d8aca4be01c2a8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Thu, Feb 27, 2025, at 22:01, Faizan Akram Dar wrote:<b=
r></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div dir=3D"auto"=
><div>Hi,<br></div><div dir=3D"auto"><div><br></div><div><br></div><div =
class=3D"qt-gmail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"qt-gmail=
_attr">On Thu, 27 Feb 2025, 20:55 Paul M. Jones, &lt;<a href=3D"mailto:p=
mjones@pmjones.io" target=3D"_blank" rel=3D"noreferrer">pmjones@pmjones.=
io</a>&gt; wrote:<br></div><blockquote class=3D"qt-gmail_quote" style=3D=
"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;bor=
der-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 20=
4, 204);padding-left:1ex;"><div><br></div><div>&gt; On Feb 25, 2025, at =
09:55, ignace nyamagana butera &lt;<a href=3D"mailto:nyamsprod@gmail.com=
" rel=3D"noreferrer noreferrer" target=3D"_blank">nyamsprod@gmail.com</a=
>&gt; wrote:<br></div><div> &gt; <br></div><div> &gt; The problem with y=
our suggestion is that the specification from WHATWG and RFC3986/3987 ar=
e 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 infor=
mation). This is why, for instance, Mat=C3=A9 added the getRaw* method a=
longside the normalized getter (method without the Raw prefix).<br></div=
><div> <br></div><div> The two functions need not return an identical ar=
ray 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 normaliz=
ed and/or raw components).<br></div><div> <br></div><div> 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.<br></div></bl=
ockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br><=
/div><div dir=3D"auto"><div class=3D"qt-gmail_quote" dir=3D"auto"><block=
quote class=3D"qt-gmail_quote" style=3D"margin-top:0px;margin-right:0px;=
margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-st=
yle:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><br></=
blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">It =
most definitely needs to be an object. Arrays are awful DX wise, there i=
s array shape which modern IDEs like phpstorm support and so does static=
 analysis but the overall experience remains subpar compared to classes =
(and objects).&nbsp;<br></div></div></blockquote><div><br></div><div>I=E2=
=80=99m curious why you say this other than an opinion about developer e=
xperience? Arrays are values, objects are not. A parsed uri seems more l=
ike a value and less like an object. Just reading through the comments s=
o 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 fo=
r other extensions and core code. In that case, a hashmap is much easier=
 to work with than a class.<br></div><div><br></div><div>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.&nbsp;<br></div><div>=
<br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body></html>
--15b8458da7fb44a685d8aca4be01c2a8--