Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124100
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-538-g1508afaa2-fm-20240616.001-g1508afaa
Precedence: bulk
MIME-Version: 1.0
Message-ID: <cbc1fb67-6b64-4038-8dad-6cb7adb6f494@app.fastmail.com>
In-Reply-To: 
 <CAH5C8xX52pf-Ee3ZvwEhvXFoz0fJFdYLi4hwkZHy8bmgjwQm0Q@mail.gmail.com>
References: 
 <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <CAJOjSBhVJqHza4XVEeEx7U=YcQZzjp_e_--dUijOf-Zf8AZs-g@mail.gmail.com>
 <CAH5C8xX52pf-Ee3ZvwEhvXFoz0fJFdYLi4hwkZHy8bmgjwQm0Q@mail.gmail.com>
Date: Sun, 30 Jun 2024 09:41:02 -0500
To: "php internals" <internals@lists.php.net>
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 Sun, Jun 30, 2024, at 1:00 AM, M=C3=A1t=C3=A9 Kocsis wrote:
>> It mirrors the interface, but it can=E2=80=99t be swapped out for a U=
riInterface instance, especially since it can=E2=80=99t be extended, so =
I wouldn=E2=80=99t consider it compatible. I would still need to write a=
 compatibility layer that composes Url\Url and implements UriInterface.
>
> I guess my words were slightly misleading: what I should have written=20
> is that the methods themselves are compatible.
>=20
>> Since PSRs are concerned with shared interfaces and this class is fin=
al and does not implement any interfaces, I=E2=80=99m not sure how you e=
nvision =E2=80=9Ca next iteration=E2=80=9D of PSR-7 to use this directly=
, unless what you mean is that UriInterface would be deprecated and appl=
ications would type directly against Url\Url.
>
> Yes, I meant the latter exactly. If we had a well-usable URL object=20
> representation in the standard library, then there would be no need to=20
> have an userland interface as well (unless they have different behavio=
r=20
> or purpose). Analogically, we have DateTimeImmutable, and there is no=20
> PSR for a date time interface. (I know there is Carbon and other=20
> libraries, but they are for convenience, not for interoperability).

I cannot speak on behalf of FIG here, but as a long-time member of FIG a=
nd a member of the Core Committee, I would urge you to *not* try to make=
 a core Url object compatible with UriInterface.  It's solving a slightl=
y different problem, using a language that is very different (PHP 8.4 vs=
 5.5 or so), with somewhat different constraints.

Instead, let's make sure that any new Url object is *composable* by PSR-=
7 UriInterface.  A UriInterface implementation that is backed by a Url o=
bject internally should be an easy task to do if anyone wants, and we sh=
ould make sure we don't do anything that makes that unnecessarily hard, =
but right now the language is simply not capable of making core Url a dr=
op-in replacement for UriInterface, so let's not even try.

Whether that means Url should be readonly or not, have getters/setters/w=
ithers, split authority into user:pass, etc. are things we should discus=
s on their own merits, not based on "well PSR-7 did it this way over 10 =
years ago, so we'll just do that."

--Larry Garfield