Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124047
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 29 Jun 2024 19:19:12 +0300
To: =?UTF-8?Q?M=C3=A1t=C3=A9_Kocsis?= <kocsismate90@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
In-Reply-To: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
References: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
User-Agent: Roundcube Webmail/1.4.8
Message-ID: <570363f9043e017025deea69131313ba@glaive.pro>
Organization: SIA "Glaive.pro"
Content-Type: multipart/alternative;
 boundary="=_a0f7d47845e25131530e12c344bbbfea"
From: juris@glaive.pro (Juris Evertovskis)

--=_a0f7d47845e25131530e12c344bbbfea
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8;
 format=flowed

On 2024-06-28 23:06, Máté Kocsis wrote:

> Hi Everyone,
> 
> I've been working on a new RFC for a while now, and time has come to 
> present it to a wider audience.
> 
> Last year, I learnt that PHP doesn't have built-in support for parsing 
> URLs according to any well established standards (RFC 1738 or the 
> WHATWG URL living standard), since the parse_url() function is 
> optimized for performance instead of correctness.
> 
> In order to improve compatibility with external tools consuming URLs 
> (like browsers), my new RFC would add a WHATWG compliant URL parser 
> functionality to the standard library. The API itself is not final by 
> any means, the RFC only represents how I imagined it first.
> 
> You can find the RFC at the following link: 
> https://wiki.php.net/rfc/url_parsing_api
> 
> Regards,
> Máté

Hey,

That's great that you've made the Url class readonly. Immutability is 
realiable. And I fully agree that a better parser is needed.

I agree with the otters that

- the enum might be fine without the backing, if it's needed at all
- I'm not convinced a separate UrlParser is needed, 
Url::someFactory($str) should be enough
- getters seem unnecessary, they should only be added if you can be sure 
they are going to be used for compatibility with PSR-7
- treating $query as a single string is clumsy, having some kind of bag 
or at least an array to represent it would be cooler and easier to build 
and manipulate

I wanted to add that it might be more useful to make all the Url 
constructor arguments optional. Either nullable or with reasonable 
defaults. So you could `$url = new Url(path: 'robots.txt'); foreach 
($domains as $d) $r[] = file_get_contents($url->withHost($d))` and stuff 
like that.

Similar modifiers would be very useful for the query stuff, e.g. `$u = 
Url::current(); return $u->withQueryParam('page', $u->queryParam->page + 
1);`.

Sure, all of that can be done in the userland as long as you drop 
`final` :)

BR,
Juris
--=_a0f7d47845e25131530e12c344bbbfea
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=
eva,sans-serif'>
<p id=3D"reply-intro">On 2024-06-28 23:06, M&aacute;t&eacute; Kocsis wrote:=
</p>
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">
<div id=3D"replybody1">
<div dir=3D"ltr">Hi Everyone,
<div>&nbsp;</div>
<div>I've been working on a new RFC for a while now, and time has come to p=
resent it to a wider audience.</div>
<div>&nbsp;</div>
<div>Last year, I learnt that PHP doesn't have built-in support for parsing=
 URLs according to any well established&nbsp;standards (RFC&nbsp;1738 or th=
e WHATWG URL living standard), since the parse_url() function is optimized =
for performance instead of correctness.</div>
<div>&nbsp;</div>
<div>In order to improve compatibility with external tools consuming&nbsp;U=
RLs (like browsers), my new RFC would add a WHATWG compliant URL parser fun=
ctionality to the standard library. The API itself is not final by any mean=
s, the RFC only represents how I imagined it first.</div>
<div>&nbsp;</div>
<div>You can find the RFC at the following link:&nbsp;<a href=3D"https://wi=
ki.php.net/rfc/url_parsing_api" target=3D"_blank" rel=3D"noopener noreferre=
r">https://wiki.php.net/rfc/url_parsing_api</a></div>
<div>&nbsp;</div>
<div>Regards,</div>
<div>M&aacute;t&eacute;</div>
<div>&nbsp;</div>
</div>
</div>
</blockquote>
<p>Hey,</p>
<p>That's great that you've made the Url class readonly. Immutability is re=
aliable. And I fully agree that a better parser is needed.</p>
<p>I agree with the otters that</p>
<p>- the enum might be fine without the backing, if it's needed at all<br /=
>- I'm not convinced a separate UrlParser is needed, Url::someFactory($str)=
 should be enough<br />- getters seem unnecessary, they should only be adde=
d if you can be sure they are going to be used for compatibility with PSR-7=
<br />- treating $query as a single string is clumsy, having some kind of b=
ag or at least an array to represent it would be cooler and easier to build=
 and manipulate</p>
<p>I wanted to add that it might be more useful to make all the Url constru=
ctor arguments optional. Either nullable or with reasonable defaults. So yo=
u could `$url =3D new Url(path: 'robots.txt'); foreach ($domains as $d) $r[=
] =3D file_get_contents($url-&gt;withHost($d))` and stuff like that.</p>
<p>Similar modifiers would be very useful for the query stuff, e.g. `$u =3D=
 Url::current(); return $u-&gt;withQueryParam('page', $u-&gt;queryParam-&gt=
;page + 1);`.</p>
<p>Sure, all of that can be done in the userland as long as you drop `final=
` :)</p>
<p>BR,<br />Juris</p>

</body></html>

--=_a0f7d47845e25131530e12c344bbbfea--