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. For more options, visit https://groups.google.com/d/optout.
