Re: [RFC] [Discussion] Followup Improvements for ext/uri

Hi Derick, > Would it make sense to have an interface for the set*() methods? Besides > build(), they all seem to have the same API. > I've just answered this to Juris, but TLDR: IMO it is not possible if we go with the currently suggested behavior. The set*() method pairs would have completely different validation rules based on the specification they implement. > > - Query Parameter Manipulation > > I see this adds NoDiscard: > #[\NoDiscard(message: "as Uri\Rfc3986\Uri::withQueryParams() does not > modify the object itself")] > > But the original methods on the classes don't have these NoDiscards, and > it doesn't seem that this RFC is suggesting to add them. It should at > least be consistent. > Thanks for noticing these; I wanted to add #[NoDiscard] to Uri/Url wither methods just before the final PHP 8.5 release, but it was a bit controversial, so I didn't do it at last. Then I thought that at least the newly proposed methods could have it, that's why I included these attributes into this RFC. But now I realized that I'm not ready to fight for them, so I've just removed them all from the proposal. > > - Accessing Path Segments as an Array > > Compare: > > "especially considering the fact that Uri\Rfc3986\Uri internally stores > the path as a list of segments." > > And: > > Uri\Rfc3986\Uri::withPathSegments() … internally concatenate the input > segments separated by a / character, and then trigger > Uri\Rfc3986\Uri::withPath() … > > Why does it need to do this concattenation, and then call withPath() for > Rfc3986\Uri then? > The path setter of the uriparser library (uriSetPathMmA) takes a string first, then reparses it as an URI (setters for the other components work much simpler), and finally, does a few other checks/modifications. If everything went well, the path is stored as a list of segments indeed. That's why concatenating the segments is needed, otherwise validation wouldn't work properly. Cheers, Máté