While this is less than ideal, I don't think having to create a new, derivative PSR is necessarily that difficult. To me, it seems to be mostly an issue of nomenclature. What really is the practical difference between calling the corrected version PSR-7 rev. B and calling it PSR-18? Since it's a breaking change, implementing packages will still need to change to make sure they implement the new interface.
There's also the additional indirection provided by the Composer package. Realistically, regardless of whether you call it PSR-7 rev. B or PSR-18, it will still be psr/http-message version 2.0.0. On Mon, Sep 26, 2016 at 9:54 PM, Rasmus Schultz <[email protected]> wrote: > Dear FIG, > > For some reason, a withServerParams() method appears to be missing from > ServerRequestInterface of PSR-7. > > Every other model property of every interface in PSR-7 has matching get_() > and with_() method pairs, but for some reason this was omitted for > server-params. > > This is proving to be problematic and rather awkward with regards to > PSR-17, the HTTP factory interfaces, where is has become impossible to > create a simple, meaningful, generic interface for the creation of a > ServerRequestInterface instance. > > It has lead to a highly regrettable but unavoidable inconsistency in the > factory-interfaces, per this thread: > > https://github.com/http-interop/http-factory/pull/20# > issuecomment-249440215 > > I can't find any mention of a withServerParams() method having ever been > mentioned or discussed in this forum, and I can't find anything is the > PSR-7 spec or meta documents stating that this was deliberately omitted for > any reason. > > This omission means that the initialization of server-params can only be > done in an implementation-specific way, e.g. by a constructor or > factory-method. > > Was this in deed a mere oversight, as it would seem, or an undocumented > deliberate choice? > > Either way, it's the sort of thing someone maintaining a piece of software > would simply correct and version-bump on any normal day. > > I was told earlier today that there is no such thing as making a > correction to a PSR, post approval, if such a correction constitutes a > breaking change? > > I don't think I need to explain why being unable (or forbidden, or even > discouraged) to correct mistakes in software is extremely problematic? > You're all software developers, and you all know the realities of software > development - software has bugs, and bugs spread, such as it would appear > to be doing in this case. > > If I understand correctly, the only way to add the missing method, would > be to start an entirely new, derivative PSR with a new number? > > Declaring an entirely new standard, as opposed to declaring a new version > of an existing standard, just to fix one problem, seems unlikely to happen > - it seems like something people would oppose on the mere grounds that > PSR-7 is already a known, well-established, widely-used thing. > > In other words, people would not logically oppose this on the grounds that > it's an insurmountable effort or in any way a severe problem to add such a > method - most projects would be able to add this method, update their > composer file, and upgrade to a new version of the interface in about two > minutes. > > Does the nature of a PSR standard itself prevent (or at least discourage) > us from making obvious, rational improvements? > > Please don't misunderstand me, I'm not pointing fingers or trying to > accuse anyone of anything - I myself reviewed PSR-7 many times while it was > in development, and never noticed this; I could have easily made this > mistake myself, for that matter. > > The issue is not who's at fault, but rather, how can we fix such mistakes? > > And if we really, truly can't (or are severely discouraged from) fixing > such mistakes, how can we remedy that situation? > > Having standards is wonderful, but being unable to correct things is > potentially detremental to the eco-system as it leads to a kind of > long-term decay that would appear to spread. > > Is this one of those "love it or shove it" situations, or can we do > something to improve this? > > Thanks, > Rasmus > > -- > You received this message because you are subscribed to the Google Groups > "PHP Framework Interoperability Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/php-fig/09d24771-1a91-4199-a98e-bd16a759a0af%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/09d24771-1a91-4199-a98e-bd16a759a0af%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAE1QayTHCNs%3DNQF4RdOAvQp0kvkjWVGfjATBghpOGVe%2BEAGjXA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
