> I can't see a reason not to have a version 1.1.0 to php-fig/http-message that will add more methods
Adding a method to an interface is a breaking change, as it renders every existing implementation invalid. I've brought this up on the list before - PSRs are not versioned, they're immutable. Which is a real problem when the "specification" consists of a package with a version number. Also, PSR-7 is already a well established "brand", so there's a disincentive to start a "competing" PSR for a seemingly minor change like this - or on other words, there's a disincentive to incrementally improve the package like you would normally do if you're a maintainer. In other words, there's no simple fix when you learn that you've made a mistake - a new PSR is the only way to go, and it will likely be really hard to get support for that... Everyone is already fully invested in PSR-7 - and it does "work", it just has this oversight that makes it clumsy and slow to add/replace headers. If I was going to propose an entirely new PSR, I would probably take another hard look at the HTTP model in its entirety - because it was modeled after PHP's CGI interface (superglobals) first and HTTP second, there's a lot of duplicate state in the model, which gets weird at times. Anyhow, I don't have much hope that a simple change to PSR-7 would pass and succeed as an entirely new PSR. > I can only guess what implementations would do with an array Headers are multi-valued, this is well covered by the spec - hence getHeaderLine() and withAddedHeader(). On Sun, Nov 11, 2018, 23:38 Alexandru Pătrănescu <[email protected] wrote: > Hi, > > In terms of packages, I can't see a reason not to have a version 1.1.0 > to php-fig/http-message that will add more methods to Psr\Http\Message\ > MessageInterface > I guess this can be achieved by another PSR, superseding PSR-7 in a > backward compatible way. > > Also, I was looking at withHeader and noticed that in docblock it mentions > that it can accept a string or an array of strings. > I can only guess what implementations would do with an array and that > would be: add each of the strings as a value for that header. > To my knowledge, there is no mention of this behavior. > > Regarding if this should have been implemented by FactoryInterface, I > think Builder pattern might look better. > > Alex > > > On Friday, November 9, 2018 at 11:47:32 AM UTC+2, Rasmus Schultz wrote: >> >> I know it's too late to bring up something like this, but... you don't >> notice until you actually start using it in real code. >> >> I wrote this class that uses PSR-17 to marshall between ResponseInterface >> and JSON-serializable data: >> >> >> https://gist.github.com/mindplay-dk/5fc5daa1cf5efd7d7ea2be99b1ec99bf#file-responsemarshaller-php-L40-L42 >> <https://www.google.com/url?q=https%3A%2F%2Fgist.github.com%2Fmindplay-dk%2F5fc5daa1cf5efd7d7ea2be99b1ec99bf%23file-responsemarshaller-php-L40-L42&sa=D&sntz=1&usg=AFQjCNHG9ZsJzAsIf0ecN33XJwQ4HeF3vA> >> >> See the highlighted lines? >> >> So, whenever you need to transfer headers from one object to another, >> currently, you have to loop over >> every individual header and manually transfer them one at a time. >> >> This has performance implications (cloning the request object for every >> individual header being copied) >> but also leads to ugly, repetitive loops like the one highlighted in the >> example above. >> >> Makes me wish we had an argument for $headers in the >> ResponseFactoryInterface method. >> >> But also makes me wonder if this was actually an oversight in PSR-7 >> itself? >> >> Like, why doesn't it have a withHeaders() method that lets you >> apply/replace all the headers? >> >> I guess as always it's too late to notice these things as PSRs are >> immutable and non-versionable? :-/ >> >> - Rasmus >> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "PHP Framework Interoperability Group" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/php-fig/aMetK_LAmsk/unsubscribe. > To unsubscribe from this group and all its topics, 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/e78ca9b9-1d0c-44c6-b629-a6f142148d72%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/e78ca9b9-1d0c-44c6-b629-a6f142148d72%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/CADqTB_gTqpPzUvKACT_dBThjub%2B_6x5JexRX8BDiR0BVtU7T7g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
