Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126975
Precedence: bulk
MIME-Version: 1.0
References: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <RYUX5rSGApW8lPGs1yovM2fIXXBHd_UcqEKAKgj8-dRrpThS4tC195Jb3kPTT5up96r7SZ2WunauAblAIEkZe41BwZxLeSE2SaKQLAYSmZo=@gpb.moe>
 <CAH5C8xXVcPM9drj-Ny5Fs_2_wnedES8-gbchaYf7z2bWne2WcQ@mail.gmail.com> <8b7044d1-fde1-4701-a914-a63c8ca67099@app.fastmail.com>
In-Reply-To: <8b7044d1-fde1-4701-a914-a63c8ca67099@app.fastmail.com>
Date: Sat, 29 Mar 2025 23:18:53 +0100
Message-ID: <CAH5C8xUA8NuWiiE+yiVAdMWFptgFp45z73XdLcgEMV6MR-4mPw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002547720631829349"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000002547720631829349
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Larry and everyone who took part in the final vs non-final debate,

Thought: make the class non-final, but all of the defined methods final,
> and any internal data properties private.  That way we know that a child
> class cannot break any of the existing guarantees, but can still add
> convenience methods or static method constructors on top of the existing
> API, without the need for an interface and a very verbose composing class=
.
>

I was thinking about this a lot, hesitating a lot on all the possibilities.
At last, I went with final classes. I know this is disappointing for
everyone who wanted to have an unlocked implementation,
and I am still sympathetic for providing some kind of extension point. I
synthesized my thoughts in a very lengthy section:
https://wiki.php.net/rfc/url_parsing_api#why_should_the_uri_rfc3986_uri_and=
_the_uri_whatwg_url_classes_be_final
so please read my full reasoning there.

TLDR: First of all, let me clarify that I want to open the API as soon as
the API becomes mature enough. However, based on the heated debate, we
would surely need a lor more time to find the best solution that won't have
unforeseen surprises. Since the final vs non-final question is a very small
(but important) detail of the proposal, I would like to discuss it on its
own, without affecting the whole work, and without risking to meet the
deadline of PHP 8.5. I really hope that this decision will give back the
focus on the most essential parts of the proposal that cannot be changed
(or only with a lot of difficulties) once the feature goes live: I mostly
think about the percent encoding/decoding related behavior, just to name
one thing.

M=C3=A1t=C3=A9

--0000000000002547720631829349
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Larry and everyone who took part in th=
e final vs non-final debate,</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">
Thought: make the class non-final, but all of the defined methods final, an=
d any internal data properties private.=C2=A0 That way we know that a child=
 class cannot break any of the existing guarantees, but can still add conve=
nience methods or static method constructors on top of the existing API, wi=
thout the need for an interface and a very verbose composing class.<br></bl=
ockquote><div><br></div><div>I was thinking about this a lot, hesitating a =
lot on all the possibilities. At last, I went with=C2=A0final classes. I kn=
ow this is disappointing for everyone who wanted to have an unlocked implem=
entation,</div><div>and I am still sympathetic for providing some kind of e=
xtension point. I synthesized my thoughts in a very lengthy section: <a hre=
f=3D"https://wiki.php.net/rfc/url_parsing_api#why_should_the_uri_rfc3986_ur=
i_and_the_uri_whatwg_url_classes_be_final">https://wiki.php.net/rfc/url_par=
sing_api#why_should_the_uri_rfc3986_uri_and_the_uri_whatwg_url_classes_be_f=
inal</a></div><div>so please read my full reasoning there.</div><div><br></=
div><div>TLDR: First=C2=A0of all, let me clarify that I want to open the AP=
I as soon as the API becomes mature enough. However, based on the=C2=A0heat=
ed=C2=A0debate, we would surely need a lor more time to find the best solut=
ion that=C2=A0won&#39;t have unforeseen surprises. Since the=C2=A0final vs =
non-final question is a very small (but important) detail of the proposal, =
I would like to discuss it on its own, without affecting the whole work, an=
d without risking to=C2=A0meet the deadline of PHP 8.5. I really hope that =
this decision will give back the focus on the most essential parts of the p=
roposal that cannot be changed (or only with a lot of difficulties) once th=
e feature goes live: I mostly think about the percent encoding/decoding rel=
ated behavior,=C2=A0just to name one thing.</div><div><br></div><div>M=C3=
=A1t=C3=A9</div><div>=C2=A0</div></div></div>

--0000000000002547720631829349--