Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126520
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <7B7987C6-37F3-432A-8BA2-9D93F428FAD5@pmjones.io>
Date: Thu, 27 Feb 2025 22:01:10 +0100
Message-ID: <CAMkukMw4V0YopJZbapczApH1h5ssKh_5yCEh5KCHSnDGiwTKzw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: "Paul M. Jones" <pmjones@pmjones.io>
Cc: 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>
Content-Type: multipart/alternative; boundary="000000000000ff00f6062f25fdce"
From: hello@faizanakram.me (Faizan Akram Dar)

--000000000000ff00f6062f25fdce
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,


On Thu, 27 Feb 2025, 20:55 Paul M. Jones, <pmjones@pmjones.io> wrote:

>
> > On Feb 25, 2025, at 09:55, ignace nyamagana butera <nyamsprod@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=C3=A9 added the g=
etRaw*
> 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() doe=
s
> 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).



> Recall that I'm responding at least in part to the comment that
> "Considering that one of the other stated goals of this RFC is to provide
> this API to other core extensions, the previous objections [to the
> Request/Response objects going into core] do not apply here." If the only
> reason they don't apply is that the core extensions need a parsing API,
> that reason becomes obviated by using just functions for the parsing
> elements.
>
> Unless I'm missing something; happy to hear what that might be.
>
>
> -- pmj
>

Imho Request and Response objects do belong in core, but with a very good
api, something which would replace http foundation/PSR7 altogether.

>

--000000000000ff00f6062f25fdce
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>Hi,</div><div dir=3D"auto"><br><br><div class=3D"gma=
il_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 27 Feb=
 2025, 20:55 Paul M. Jones, &lt;<a href=3D"mailto:pmjones@pmjones.io" targe=
t=3D"_blank" rel=3D"noreferrer">pmjones@pmjones.io</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
&gt; On Feb 25, 2025, at 09:55, ignace nyamagana butera &lt;<a href=3D"mail=
to:nyamsprod@gmail.com" rel=3D"noreferrer noreferrer" target=3D"_blank">nya=
msprod@gmail.com</a>&gt; wrote:<br>
&gt; <br>
&gt; 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&#39;t be able to cover the outcome correctly (ie give the developper al=
l the needed information). This is why, for instance, Mat=C3=A9 added the g=
etRaw* method alongside the normalized getter (method without the Raw prefi=
x).<br>
<br>
The two functions need not return an identical array of components; e.g., t=
he 3986 parsing function might return an array much like parse_url() does n=
ow, and the WHATWG function might return a completely different array of co=
mponents (one that includes the normalized and/or raw components).<br>
<br>
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></=
blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></=
div><div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"></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 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).=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<br>
Recall that I&#39;m responding at least in part to the comment that &quot;C=
onsidering that one of the other stated goals of this RFC is to provide thi=
s API to other core extensions, the previous objections [to the Request/Res=
ponse objects going into core] do not apply here.&quot; If the only reason =
they don&#39;t apply is that the core extensions need a parsing API, that r=
eason becomes obviated by using just functions for the parsing elements.<br=
>
<br>
Unless I&#39;m missing something; happy to hear what that might be.<br>
<br>
<br>
-- pmj<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"=
auto">Imho Request and Response objects do belong in core, but with a very =
good api, something which would replace http foundation/PSR7 altogether.</d=
iv><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
</blockquote></div></div></div>

--000000000000ff00f6062f25fdce--