On Wednesday, 7 May 2025 at 20:20, Paul M. Jones <pmjo...@pmjones.io> wrote:
> 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. > [...] > > -- pmj Considering that this RFC was in discussion for over 10 months, and you only started providing input 2 months ago after there have already been serious alterations to it _twice_. I am not sure your "rant" is something that is at all productive. You are free to vote against it, but stalling the work someone has committed just because you don't think it is ready is not how any of this works. Looking from the sidelines, you seem to have the opinion that we should be standardizing existing userland design. This is not what you want, because if you do this you get POSIX, and POSIX is notoriously inconsistent and kinda bad. And maybe this is what FIG did, which whatever, but core is not FIG nor userland. So let's go through your points: > - is too broad in scope; An RFC author is allowed to choose whatever scope they want. > - acknowledges it is incomplete, with work left undone; Using multiple RFCs to provide incremental improvements to the language is a standard thing we do. Therefore, this point is moot. > - admits to standards non-compliance; and, Non-compliance with what? WHATWG which is a living standard? Not having one component of the WHATWG spec? The same way, the new 8.4 DOM classes don't implement the whole living DOM spec? > - has an uncertain API. Frankly, 90% of the recent uncertainty has seemingly come from you trying to "rework" the RFC to your own taste. If you think this should first be an extension or a userland package then feel free to do it, regardless of the result of this vote. Considering that one of the main maintainers of an actual popular userland URI library has actively been participating in the discussions since the beginning and help shape this RFC, makes me believe this is very much ready to vote, compared to the opinion of someone that is trying to chime in last minute. Sincerely, Gina P. Banyard
