Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126930
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> <9bf11a89-39d9-457b-b0ea-789fd07d7370@gmail.com>
 <CAH5C8xWnoytE=jm1sxr-HcSZFzmG8SrzghinmBZa-QyGqN4uUg@mail.gmail.com>
 <6430b9ed-638d-4247-9fa9-d1a9148c382b@gmail.com> <CAH5C8xX3tCS3B3z2YFbRudCXi=ZNHE0scrmoFO7cXxU773EfpA@mail.gmail.com>
 <1FD11284-D682-4CB7-893F-D74A1904610D@pmjones.io> <CAH5C8xVGDhDgLp0QWabx6BudAvRAcF9sVt+gR0R0C-bF3E1hRw@mail.gmail.com>
 <A465491B-0F03-46D4-AE10-550DF336FDE8@pmjones.io>
In-Reply-To: <A465491B-0F03-46D4-AE10-550DF336FDE8@pmjones.io>
Date: Tue, 25 Mar 2025 09:45:12 +0100
Message-ID: <CAH5C8xXjKb_44QqH9+G5LifbDwCLXq9ieisptYxqBy_XsJUytA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: "Paul M. Jones" <pmjones@pmjones.io>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d5a317063126bde2"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000d5a317063126bde2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Paul,

## Rowbot
>
> (None of the classes are readonly or final; these look to hew closely to
> the WHATWG-URL spec.)
>
> A BasicURLParser class:
>
> - affords relative parsing capability and an option parameter for the
> target URLRecord
> - returns a URLRecord
>
> A URLRecord class:
>
> - public mutable properties for the URL components
> - $scheme is a Scheme implementation with equals() and other is...()
> methods
> - $host is a HostInterface (and implementations) with equals() and other
> is...() methods
> - $path is a PathInterface (and PathList implementation) with PathSegment
> manipulation methods
> - setUsername() and setPassword() mutators
> - serializing
> - getOrigin(), includesCredentials(), isEqual()
>
> A URL class:
>
> - Composed of a URLRecord and a URLSearchParams object
> - Constructor takes a string, parses it to a URLRecord, and retains the
> URLRecord
> - a static parse() method with relative parsing, as a convenience method
> - __toString() and toString() return the serialized URLRecord
> - Virtual properties for $href, $origin, $protocol, $username, $password,
> $host, $hostname, $port, $pathname, $search, $searchParams, $hash
> - Mutability of virtual properties via magic __set()
> - Readability of virtual properties via magic __get()
>

I like some of the solutions this library uses - the usage of dedicated
value objects for some components (Scheme, HostInterface, PathInterface) -,
but
these features are what make the implementation extremely slow compared to
the implementation the RFC proposes. I didn't dig into the details when
I performed a very quick benchmark last week, so I can only assume that the
excessive usage of objects makes the library much slower than what's
possible
even for a userland library (obviously, an internal C implementation will
always be faster). According to my results, the RFC's implementation was
**two orders of magnitude** faster than the Rowbot library for parsing a
very basic "https://example.com" URL 1000 times (~0.002 sec vs ~0.56 sec).

What I want to say with this is that it's perfectly fine to optimize a
userland library for ergonomics and for the usage of advanced OOP in mind,
but an internal
implementation should also keep efficiency in mind besides developer
experience. That's why I don't see myself implement separate objects for
some of
the components for now. But nothing would block us from doing it later, if
we found out it's necessary.

I believe the most fundamental difference between the Rowbot library and
the RFC is that the RFC has native support for percent-decoding (because
most properties are accessible in 2 variants), while the library completely
leaves this task for the user. Apart from that, the mutable design of the
library
is fragile for the same reason as the DateTime class is not safe to use in
most cases, so that's definitely a no-go for me.

This RFC is a synthesis of almost a year of discussion and refinement,
collaborated by some very clever folks, who have a lot of hands-on
experience of
URL parsing and handling. That's why I would say that input from Trevor
Rowbotham is also welcome in the discussion (especially his experience of
some
edge cases he had to deal with), but the said library is nowhere near as
widely adopted for it to qualify as something we must definitely take into
consideration
when designing PHP's new URL parsing API.


> A URLSearchParams class:
>
> - search params manipulation methods
> - implements Countable, Iterator, Stringable
> - composed of a QueryList implementation and (optionally) the originating
> URLRecord
>
>
I like this concept too. And in fact, support for such a class is on my
to-do list, and is mentioned in the "Future Scope". I just didn't want to
make the RFC
even longer, because we already have a lot of details to discuss.

M=C3=A1t=C3=A9

--000000000000d5a317063126bde2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Paul,</div><div dir=3D"ltr"><br></div>=
<div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">
## Rowbot<br>
<br>
(None of the classes are readonly or final; these look to hew closely to th=
e WHATWG-URL spec.)<br>
<br>
A BasicURLParser class:<br>
<br>
- affords relative parsing capability and an option parameter for the targe=
t URLRecord<br>
- returns a URLRecord<br>
<br>
A URLRecord class:<br>
<br>
- public mutable properties for the URL components<br>
- $scheme is a Scheme implementation with equals() and other is...() method=
s<br>
- $host is a HostInterface (and implementations) with equals() and other is=
...() methods<br>
- $path is a PathInterface (and PathList implementation) with PathSegment m=
anipulation methods<br>
- setUsername() and setPassword() mutators<br>
- serializing<br>
- getOrigin(), includesCredentials(), isEqual()<br>
<br>
A URL class:<br>
<br>
- Composed of a URLRecord and a URLSearchParams object<br>
- Constructor takes a string, parses it to a URLRecord, and retains the URL=
Record<br>
- a static parse() method with relative parsing, as a convenience method<br=
>
- __toString() and toString() return the serialized URLRecord<br>
- Virtual properties for $href, $origin, $protocol, $username, $password, $=
host, $hostname, $port, $pathname, $search, $searchParams, $hash<br>
- Mutability of virtual properties via magic __set()<br>
- Readability of virtual properties via magic __get()<br></blockquote><div>=
<br></div><div>I like some of the solutions this library uses - the usage o=
f dedicated value objects for some components (Scheme, HostInterface, PathI=
nterface) -, but</div><div>these features are what make the implementation =
extremely slow compared to the implementation the RFC proposes. I didn&#39;=
t dig into the details when</div><div>I performed a very quick benchmark la=
st week, so I can only assume that the excessive usage of objects makes the=
 library much slower than what&#39;s possible</div><div>even for a userland=
 library (obviously, an internal C implementation will always be faster). A=
ccording to my results, the RFC&#39;s implementation was</div><div>**two or=
ders of magnitude** faster than the Rowbot library for parsing a very=C2=A0=
basic &quot;<a href=3D"https://example.com">https://example.com</a>&quot; U=
RL 1000 times (~0.002 sec vs ~0.56 sec).</div><div><br></div><div>What I wa=
nt to say with this is that it&#39;s perfectly fine to optimize a userland =
library for ergonomics and for the usage of advanced OOP in mind, but an in=
ternal</div><div>implementation should also keep=C2=A0efficiency in mind be=
sides developer experience. That&#39;s why I don&#39;t see myself implement=
 separate objects for some of</div><div>the components for now. But nothing=
 would block us from doing it later, if we found out it&#39;s necessary.</d=
iv><div><br></div><div>I believe the most fundamental difference between th=
e Rowbot library and the RFC is that the RFC has native support for percent=
-decoding (because</div><div>most properties are accessible in 2 variants),=
=C2=A0while the library completely leaves this task for the user. Apart fro=
m that, the mutable design of the library</div><div>is fragile for the same=
 reason as the DateTime class is not safe to use in most cases, so that&#39=
;s definitely a no-go for me.</div><div><br></div><div>This RFC is a synthe=
sis of almost a year of discussion and refinement, collaborated by some ver=
y clever folks, who have a lot of hands-on experience of</div><div>URL pars=
ing and handling. That&#39;s why I would say that input from Trevor Rowboth=
am is also welcome in the discussion (especially his experience of some</di=
v><div>edge cases he had to deal with), but the said library is nowhere nea=
r as widely adopted for it to qualify as something we must definitely take =
into consideration</div><div>when designing PHP&#39;s new URL parsing API.<=
/div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
A URLSearchParams class:<br>
<br>
- search params manipulation methods<br>
- implements Countable, Iterator, Stringable<br>
- composed of a QueryList implementation and (optionally) the originating U=
RLRecord<br>
<br></blockquote><div><br></div><div>I like this concept too. And in fact, =
support for such a class is on my to-do list, and is mentioned in the &quot=
;Future Scope&quot;. I just didn&#39;t want to make the RFC</div><div>even =
longer, because we already have a lot of details to discuss.</div><div><br>=
</div><div>M=C3=A1t=C3=A9</div></div></div>

--000000000000d5a317063126bde2--