Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126709
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 10 Mar 2025 23:34:37 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <8b7044d1-fde1-4701-a914-a63c8ca67099@app.fastmail.com>
In-Reply-To: 
 <CAH5C8xXVcPM9drj-Ny5Fs_2_wnedES8-gbchaYf7z2bWne2WcQ@mail.gmail.com>
References: 
 <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <RYUX5rSGApW8lPGs1yovM2fIXXBHd_UcqEKAKgj8-dRrpThS4tC195Jb3kPTT5up96r7SZ2WunauAblAIEkZe41BwZxLeSE2SaKQLAYSmZo=@gpb.moe>
 <CAH5C8xXVcPM9drj-Ny5Fs_2_wnedES8-gbchaYf7z2bWne2WcQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Mar 10, 2025, at 5:51 PM, M=C3=A1t=C3=A9 Kocsis wrote:

> I'm sure that people will find their use-cases to subclass all these=20
> new classes, including the WHATWG implementation. As Nicolas mentioned,
> his main use-case is minly adding convenience and new factory methods=20
> that don't specifically need all methods to be reimplemented.
>
> While I share your opinion that leaving the URI classes open for=20
> extension is somewhat risky and it's difficult to assess its impacts=20
> right now, I can also
> sympathise with what Nicolas wrote in a later message=20
> (https://externals.io/message/123997#126489): that we shouldn't close=20
> the door for the public from
> using interchangeable implementations.
>
> I know that going final without any interfaces is the most "convenient=
"=20
> for the PHP project itself, because the solution has much less BC=20
> surface to maintain,
> so we are relatively free and safe to make future changes. This is=20
> useful for an API in its early days that is huge like this. Besides th=
e=20
> interests of the maintainers,
> we should also take two important things into account:
>
> - Heterogeneous use-cases: it's out of question that the current API=20
> won't fit all use-cases, especially because we have already identified=20
> some followup tasks
> that should be implemented (see "Future Scope" section in the RFC).
> - Interoperability: Since URI handling is a very widespread problem,=20
> many people and libraries will start to use the new extension once it'=
s=20
> available. But because
> of the above reason, many of them want to use their own abstraction,=20
> and that's exactly why a common ground is needed: there's simply not a=20
> single right possible
> implementation - everyone has their own, given the complexity of the=20
> topic.
>
> So we should try to be considerate about these factors by some way or=20
> another. So far, we have four options:
>
> - Making the classes open for extension: this solution has acknowledge=
d=20
> technical challenges=20
> (https://github.com/php/php-src/pull/14461#discussion_r1847316607),
> and it limits our possibilities of adding changes the most, but users=20
> can effectively add any behavior that they need. Of course, they are=20
> free to introduce bugs and
> spec-incompatible behavior into their own implementation, but none of=20
> the other solutions could prevent such bugs either, since people will=20
> write their custom code
> wherever they can: if they can't have it in a child class, then they=20
> will have in MyUri, or in UriHelper, or just in a 200 lines long=20
> function.
>
> Being able to extend the built-in classes also means that child classe=
s=20
> can use the behavior of their parent by default - there's no need to=20
> create wrapper
> classes around the built-in ones (aka using composition), that is a=20
> tedious task to implement, and also which would incur some performance=20
> penalty because of the
> extra method calls.
>
> - Making the classes open for extension, but making some methods final=
:=20
> same benefits as above, without the said technical challenges - in=20
> theory. I am currently
> trying to figure out if there is a combination of methods that could b=
e=20
> made final so that the known challenges become impossible to be=20
> triggered - although I haven't
> managed to come up with a sensible solution yet.
>
> - Making the classes final: It avoids some edge-cases for the built-in=20
> classes (the uninitialized state most prominently), while it leaves th=
e=20
> most room for making future
> changes. Projects that may want to ship their own abstractions for the=20
> two built-in classes can use composition to create their own URI=20
> implementations.
> They can instantiate these implementations however they want to (i.e.=20
> $myUri =3D new MyUri($uri)). If they need to pass an URI to other=20
> libraries then they could extract
> the wrapped built-in class (i.e. $myUri->getUri()).
>
> On the flipside, backporting methods added in future PHP versions (aka=20
> polyfills) will become impossible to implement for URIs according to m=
y=20
> knowledge, as well as mocking
> in PHPUnit will also be a lost feature (I'm not sure if it's a good or=20
> a bad thing, but it may be worth to point out).
>
> Also, the current built-in implementations may have alternative=20
> implementations that couldn't be used instead of them. For example, th=
e=20
> ADA URL library (which is mentioned
> in the RFC) also implements the WHATWG specification - possibly the=20
> very same way as Lexbor, the currently used library - does. These=20
> alternative implementations may have
> different performance characteristics, platform requirements, or level=20
> of maintenance/support, which may qualify them as more suitable for=20
> some use-cases than what the built-in
> ones can offer. If we make these classes final, there's no way to use=20
> alternative implementations as a replacement for the default ones,=20
> although they all implement the same
> specification having mostly clear semantics.
>
> - Making the classes final, but adding a separate interface for each:=20
> The impact of making the built-in classes final would be mitigated by=20
> adding one interface
> for each specification (I didn't like this idea in the past, but it no=
w=20
> looks much more useful in the perspective of the final vs non-final=20
> debate). Because of the interfaces,
> there would be a common denominator for the different possible=20
> implementations. I'm sure that someone would suggest that the communit=
y=20
> (aka PHP-FIG)
> should come up with such an interface, but I think we shouldn't expect=20
> someone else to do the work when *we* are in the position to do it the=20
> best, as those interfaces
> should be internal ones, since the built-in URI classes should also=20
> implement them.
>
> If we had these interfaces, projects could use whatever abstraction=20
> they want via composition, but they could more conveniently pass aroun=
d=20
> the same object everywhere.
>
> I intentionally don't try to draw a conclusion for now, first of all=20
> because it already took me a lot of time to try to mostly objectively=20
> compare the different possibilities, and
> I hope that we can find more pros-cons (or fix my reasonings if I made=20
> mistakes somewhere) in order to finally reach some kind of consensus.

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 chil=
d class cannot break any of the existing guarantees, but can still add c=
onvenience methods or static method constructors on top of the existing =
API, without the need for an interface and a very verbose composing clas=
s.

--Larry Garfield