Hi Maté and all, > On May 5, 2025, at 16:36, Máté Kocsis <kocsismat...@gmail.com> wrote: > > Hello Internals, > > After more than a hundred emails refining even the tiniest details, we have > reached a point where I'd like to call for a vote. > I know that the new API still doesn't support many use-cases, it still has > missing pieces, but now it includes a cohesive set > of functionality that could be a very useful basic building block for most > people. > > That said, I don't intend to change anything about the RFC anymore, unless > there's still some factual error in it. There are a lot of > possibilities how such a large API can look like, and this RFC approaches the > problem the way it is currently described, > and not in any other way. > > So unless some very serious issues arise, I'm going to start the vote on 8th > May, possibly in the morning (according to UTC).
I am on record as wanting very much to see some decent web-centric objects in core PHP (Request, Response, Uri/Url, etc). To my chagrin, despite the fact that its goals are laudable, I do not think this RFC is in a ready state to provide such objects. Among other things I find troubling, the RFC as presented ... - is too broad in scope; - acknowledges it is incomplete, with work left undone; - admits to standards non-compliance; and, - has an uncertain API. ## Too Broad In Scope The RFC attempts to do too much at once: not just making URI/URL parsing "pluggable" for internals, and providing an RFC 3986 compliant parser, but also creating from scratch entirely new RFC 3986 URI and related Exception classes for userland consumption, along with entirely new WHATWG-URL classes and Exceptions. The RFC itself remarks on "[t]he already large scope of the RFC" -- and the same has been observed during the on-list discussions. Even Maté's message above mentions "There are a lot of possibilities how such a large API can look like". It would be better to narrow the scope of the RFC to something more manageable. ## Incomplete, Work Left Undone This is a consequence of the overly-broad scope. The work remaining is by no means certain to be completed or voted in after followup RFCs, either on a short timeline or a long one. Maté notes above that the RFC "has missing pieces" -- and here are some examples from the RFC itself: - "Builder classes are not offered by the present RFC just yet. ... this feature is one of the top candidates of a followup RFC." - "The topic of query parameter manipulation should be discussed as a followup to the current RFC." - "There are multiple planned features in future scope that should be supported." - "There are immediate plans to add new capabilities to the new API" - "the position of this RFC is not to include this interface [URLSearchParams] yet" It would better to present a single finished product instead of multiple partially-finished products. ## Standards Non-Compliance The RFC states early on that "the parse_url() function is offered for parsing URLs, however, it isn't compliant with any standards. ... Incompatibility with current standards is a serious issue" -- but later it says: > Getters of Uri\WhatWg\Url have a few gotchas for the ones who are inherently > familiar with the WHATWG URL specification: they don't (entirely) follow the > “getter steps” that are defined by the specification, but the individual > components are returned directly without any other changes that the “getter > steps” would otherwise specify. The RFC doesn't fully follow the WHATWG-URL standard. This is reminiscent of the complaint regarding parse_url(). Further, "the WHATWG URL specification contains a URLSearchParams interface" but "the position of this RFC is not to include this interface yet". It would be better to actually follow the WHATWG-URL standard, and not add a partially-compliant and somewhat-nonstandard implementation to core. ## Uncertain API Because of the unfinished work, and because of the "living standard" nature of WHATWG-URL, the foundation of the API is unsteady: > WHATWG URL doesn't specify percent-decoding rules for most components ... But > since the WHATWG URL specification is subject to constant updates, it's > possible that normalization or percent-decoding rules change in the future. "Constant updates" makes me think it is too early to include a WHATWG-URL implementation in core. Then we have this ... > the current RFC chooses to make the built-in URI implementations final ... > until the new API becomes mature enough and becomes tested in practice. ... and this: > Once the API settles, we plan to lift these restrictions [around final > classes] at some extent. If the API needs to "become tested in practice" so that it can "mature" and "settle", it would be better do that in userland (maybe published on Packagist or PECL) instead of in core. ## Remedies I think all of the above can be remedied, so that we can finally have some decent web-centric objects in core. But that's a discussion for a later time, one we can have if the RFC does not pass. -- pmj
