Intervention
Remove dependency on an specific PSR-7 package
Right now this package depends on guzzlehttp\psr7 which contradicts the point of PSR-7. It should be possible to use any PSR-7 package that provides a response class compatible with ResponseInterface, such as zendframework/zend-diactoros.
This would necessitate a functionality change in the PsrResponseCommand to pass in a ResponseInterface and use the immutable methods to define a modified response.
Thanks for your suggestion. I will keep this in mind for the next version.
Right now this package depends on guzzlehttp\psr7 which contradicts the point of PSR-7.
PSR-7 implementation was added to support simplified response generation, i'm not seeing any reason why using specific package are the problem since response compatible with any existed PSR7 library (i personally use it's responses with zendframework/zend-diactoros as http component), guzzle was used only due it's fairly small and well tested.
Obviously, your point has sence, method can accept incoming request to perform immutable manipulations, hovewer this seems to be much ligther solution and command can support both ways without any violations (i can't see many scenarious when binary image data has to be written to existed response, to preserve headers only?).
Hovewer, you right. Someone might not want to include guzzle/psr7, in this case package can be moved to recommended list and simplified fallback code can be applied only if it was connected.
The difference is deceptively small. Consider the following calling code:
$response = $image->getResponse(new Response);
// vs
$response = $image->getResponse();
The former supports dependency injection and allows using any PSR-7 compatible response. For example, the framework I am using might already depend on a PSR-7 implementation which I can reuse to send image responses. The latter assumes a specific implementation of HTTP responses. It makes more sense to reuse whatever existing PSR-7-compatible package I already have installed than to install another one that implements the same interface.
PSR-7 was created precisely because this kind of situation. Now that the PSR exists, we can simply depend on the interfaces and not worry about the implementation.
I think you're right. Depending on a specific PSR-7 package is questionable. I will change this.
That's exacly what i wrote in my last comment, i completelly agree with you on this point.
But, just for educational purposes i would like to confirm for myself:
The former supports dependency injection and allows using any PSR-7 compatible response.
I assume the point of PSR7 is not only to create set of communication interfaces but also provide specific requiments for implementations, meaning guzze response will behave excacly the same as phly/zend one - the only difference is in constructor which is hidden for user in case of fallback code.
The only point is about adding one more dependency for simplification, which again, i agree can be unnesessary in some cases. Theoretically, Intervention/image can implement it's own PSR7 compatible response and use it as fallback untill it follows PSR7 standard.
PSR7 is not only to create set of communication interfaces but also provide specific requiments for implementations
That is exactly what the interfaces do.
adding one more dependency for simplification
It's only a matter of explicit vs implicit dependency. If you depend on a concrete implementation of PSR-7 such as guzzle/psr7 you are already implicitly depending on psr/http-message. By depending only on psr/http-message you actually remove a dependency.
a simple fix might be to move guzzlehttp/psr7 to the "suggest" block in composer.json?
