Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124025
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-538-g1508afaa2-fm-20240616.001-g1508afaa
Precedence: bulk
MIME-Version: 1.0
Message-ID: <f8d8b600-167b-441e-a35d-e147720dd36f@app.fastmail.com>
In-Reply-To: <5159E0AB-C8B0-4A54-9654-986C1D9C858F@koalephant.com>
References: <71a73b87-cc2f-4ee5-a961-7bf2b191fbb6@gmail.com>
 <5159E0AB-C8B0-4A54-9654-986C1D9C858F@koalephant.com>
Date: Sat, 29 Jun 2024 12:33:16 +0200
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
Content-Type: multipart/alternative;
 boundary=9dc7c13bbfdc4aa99ce650483b098750
From: rob@bottled.codes ("Rob Landers")

--9dc7c13bbfdc4aa99ce650483b098750
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 29, 2024, at 11:57, Stephen Reay wrote:
>=20
>=20
> > On 29 Jun 2024, at 04:48, Niels Dossche <dossche.niels@gmail.com> wr=
ote:
> >=20
> > - It's a bit of a shame that the PSR interface treats queries as str=
ings.
> > In Javascript we have the URLSearchParams class that we can use as a=
 key-value storage for query parameters.
> > This Javascript class also handles escaping them nicely.
>=20
> Agreed this is a weird choice to me, but I'm also not surprised by wei=
rd choices via
> php-fig (log level constants I'm looking at you)
>=20
> We hear all the time how userland is more flexible and can change quic=
ker - and yet here we see a potential built in class having a worse api =
because it wants to be compatible with an existing userland interface wi=
th the same bad api....
>=20
> Cheers
>=20
> Stephen =20

I personally ignore PSR when it doesn't make sense to use it. They're ni=
ce for library compatibility, but I will happily toss compatibility when=
 it doesn't make sense to be compatible. This might be one of those case=
s as there is no reason it has to be PSR compliant. In fact, a wrapper m=
ay be written to make it compliant, if one so chooses. I suspect it is b=
etter to be realistic and learn from the short-comings of PSR and apply =
those learnings here, vs. reiterating them and "engraving them in stone"=
 (so to speak).

=E2=80=94 Rob
--9dc7c13bbfdc4aa99ce650483b098750
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>On Sat, Jun 29,=
 2024, at 11:57, Stephen Reay wrote:<br></div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div><br></div><div><br></div><div>&gt; On 29 Jun 2=
024, at 04:48, Niels Dossche &lt;<a href=3D"mailto:dossche.niels@gmail.c=
om">dossche.niels@gmail.com</a>&gt; wrote:<br></div><div>&gt;&nbsp;<br><=
/div><div>&gt; - It's a bit of a shame that the PSR interface treats que=
ries as strings.<br></div><div>&gt; In Javascript we have the URLSearchP=
arams class that we can use as a key-value storage for query parameters.=
<br></div><div>&gt; This Javascript class also handles escaping them nic=
ely.<br></div><div><br></div><div>Agreed this is a weird choice to me, b=
ut I'm also not surprised by weird choices via<br></div><div>php-fig (lo=
g level constants I'm looking at you)<br></div><div><br></div><div>We he=
ar all the time how userland is more flexible and can change quicker - a=
nd yet here we see a potential built in class having a worse api because=
 it wants to be compatible with an existing userland interface with the =
same bad api....<br></div><div><br></div><div>Cheers<br></div><div><br><=
/div><div>Stephen&nbsp;&nbsp;<br></div></blockquote><div><br></div><div>=
I personally ignore PSR when it doesn't make sense to use it. They're ni=
ce for library compatibility, but I will happily toss compatibility when=
 it doesn't make sense to be compatible. This might be one of those case=
s as there is no reason it has to be PSR compliant. In fact, a wrapper m=
ay be written to make it compliant, if one so chooses. I suspect it is b=
etter to be realistic and learn from the short-comings of PSR and apply =
those learnings here, vs. reiterating them and "engraving them in stone"=
 (so to speak).<br></div><div><br></div><div id=3D"sig121229152">=E2=80=94=
 Rob<br></div></body></html>
--9dc7c13bbfdc4aa99ce650483b098750--