PSR-13 support

[Crell]

I know this library is intended to be a "pure" implementation of PSR-7 and its related PSRs. However, that means it also supports PSR-15 and PSR-17. What about PSR-13?

PSR-13 isn't strictly about HTTP, but it was built with the very explicit intent of being able to enhance PSR-7 responses. Having a well-defined and supported object that supports 7 and 13 would let us easily type check against it using intersection types now that we have those (yay!).

Would you accept a PR to add PSR-13 compatibility to response objects? (I'm happy to write the PR, but want to make sure it would be accepted first.)

[nicolas-grekas]

I'd say the reason is that there is already https://github.com/symfony/web-link on the topic, with great maintenance policies, so no need to duplicate the effort.

[Crell]

That's not what I'm talking about. symfony/web-link is a duplicate of fig/link-util, or close to. I'm talking about

namespace Nyholm\Psr7;

class Response implements ResponseInterface, EvolvableLinkProviderInterface { ... }

[nicolas-grekas]

I can see how that could make sense from a consumer PoV, but from a design PoV, I'm not convinced:

If Response implements EvolvableLinkProviderInterface but doesn't provide an implementation of LinkInterface, we're still asking ppl to install another dep for getting 100% of PSR-13. If you have to install a dep (and couple yourself to it, at least to instantiate Link objects), then you can deal with using another object to store links.

And if this lib ships PSR-13, well, we increase its scope, which might not desired either.

[Crell]

I figured I'd just depend on fig/link-util, which exists for exactly this purpose. Yes it's a dependency, Packagist says it has 53 million installs, so it's likely already in a lot of projects anyway.

PSR-13 was built for exactly this use case (enhancing PSR-7), and it's now easy with intersection types, so having one of the major PSR-7 implementations not support it is quite sad.