Hi all,
> On May 7, 2025, at 17:02, Gina P. Banyard <[email protected]> wrote:
>
> On Wednesday, 7 May 2025 at 20:20, Paul M. Jones <[email protected]> wrote:
>
>> 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
Putting these together, one from the beginning ...
> 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_.
... and one from the end:
> the opinion of someone that is trying to chime in last minute.
Sure, I can see what it looks like: Johnny-come-lately starts making noise only as things are
finishing up.
I can say only that (at least from my perspective) there was no sure way to tell how much longer
discussion would go on, or how many more changes might be considered. Based on other experiences,
conscience demanded that I offer comments as requested on the RFC, as many others had before me.
> I am not sure your "rant" is something that is at all productive.
I am glad for the scare quotes; it was a factual analysis, not a rant. As to whether it is
productive, well, one never knows until afterwards.
> You are free to vote against it,
I might? If I do, it strikes me as constructive (and polite) to have provided reasons why -- thus my
message.
> but stalling the work someone has committed just because you don't think it is ready is
> not how any of this works.
To be fair, just because someone has committed work does not mean the work should be accepted; but,
my individual opinion is of relatively little weight there.
> Looking from the sidelines, you seem to have the opinion that we should be standardizing
> existing userland design.
Not exactly. My opinion is that the RFC should consider the approaches taken by the many others that
have produced working URI solutions; and, if those approaches are discarded, then articulate the
reasons for doing so. To ignore them out of hand is insufficiently diligent.
> So let's go through your points:
>
>> - is too broad in scope;
>
> An RFC author is allowed to choose whatever scope they want.
I did not say otherwise; whether the scope chosen is a good one or not is something else.
>> - has an uncertain API.
>
> Frankly, 90% of the recent uncertainty has seemingly come from you trying to "rework"
> the RFC to your own taste.
First, the uncertainty I referred to was from the RFC itself, when it states that the API needs to
become "mature enough" and "tested in practice" until it "settles."
That tells me the authors aren't too sure of it.
Then, to be clear, those observations and suggestions were not based on my "own taste."
They are based the decisions of a dozen or so developers working in the URI space, research into
which is summarized at <https://github.com/uri-interop/interface/blob/1.x/README-RESEARCH.md>.
>> - admits to standards non-compliance; and,
>
> Non-compliance with what?
I mentioned this in the earlier message, but to reiterate: the WHATWG-URL getters "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."
* * *
So, those are some of my concerns around the RFC. Take them or leave them, as you see fit. If the
RFC passes, it won't be the worst thing that that ever happened to PHP, and if it turns out
that my concerns were unfounded, so much the better.
-- pmj