On Sun, Jun 30, 2024, at 1:00 AM, Máté Kocsis wrote: >> It mirrors the interface, but it can’t be swapped out for a UriInterface >> instance, especially since it can’t be extended, so I wouldn’t 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 > is that the methods themselves are compatible. > >> Since PSRs are concerned with shared interfaces and this class is final and >> does not implement any interfaces, I’m not sure how you envision “a next >> iteration” of PSR-7 to use this directly, unless what you mean is that >> UriInterface would be deprecated and applications would type directly >> against Url\Url. > > Yes, I meant the latter exactly. If we had a well-usable URL object > representation in the standard library, then there would be no need to > have an userland interface as well (unless they have different behavior > or purpose). Analogically, we have DateTimeImmutable, and there is no > PSR for a date time interface. (I know there is Carbon and other > 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 and 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 slightly 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 object internally should be an easy task to do if anyone wants, and we should 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 drop-in replacement for UriInterface, so let's not even try. Whether that means Url should be readonly or not, have getters/setters/withers, split authority into user:pass, etc. are things we should discuss 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
