On Sat, Jun 29, 2024, at 11:57, Stephen Reay wrote: > > > > On 29 Jun 2024, at 04:48, Niels Dossche <dossche.ni...@gmail.com> wrote: > > > > - It's a bit of a shame that the PSR interface treats queries as strings. > > In Javascript we have the URLSearchParams class that we can use as a > > key-value storage for query parameters. > > This Javascript class also handles escaping them nicely. > > Agreed this is a weird choice to me, but I'm also not surprised by weird > choices via > php-fig (log level constants I'm looking at you) > > We hear all the time how userland is more flexible and can change quicker - > and yet here we see a potential built in class having a worse api because it > wants to be compatible with an existing userland interface with the same bad > api.... > > Cheers > > Stephen
I personally ignore PSR when it doesn't make sense to use it. They're nice for library compatibility, but I will happily toss compatibility when it doesn't make sense to be compatible. This might be one of those cases as there is no reason it has to be PSR compliant. In fact, a wrapper may be written to make it compliant, if one so chooses. I suspect it is better to be realistic and learn from the short-comings of PSR and apply those learnings here, vs. reiterating them and "engraving them in stone" (so to speak). — Rob
