PHP provides a DateTimeInterface and multiple implementations thereof, so some programmers *do* want different implementations of DateTime. Streams are defined as a big part of PSR-7, so I'm not sure why they shouldn't matter to an implementing library. Both requests and responses have their bodies defined as being instances of Psr\Http\Message\StreamInterface.
There's no reason a library couldn't do something similar with request/response objects and offer a few implementations. I'm not sure if any PSR-7 libraries have done so, but Symfony's HttpFoundation provided a few subclasses of Response for common use cases (like BinaryFileResponse, JsonResponse, and RedirectResponse). A PSR-7 library might choose to implement something similar. On Monday, June 27, 2016 at 11:12:55 AM UTC-7, Daniel Plainview wrote: > > > I'd say that the variety of stream implementations is one of the reasons > someone would opt to use Guzzle's PSR-7 library instead of another, so it > seems to directly answer the original poster's question > > No, it's not. > > Please, pay attention that I talk about *value objects* Request and > Response. > > Stream is not a value object, it's more like a service. > Stream may have external dependencies, different implementations. > Having interface for the Steam is perfectly fine. > This part of PSR (streams) is the space for different implementations of > course. > > However, value objects are different story. > They shouldn't have external dependencies. > They are not services. > You don't want to have different implementations of DateTime, > DateInterval, DateTimeZone, etc. > > On Monday, June 27, 2016 at 8:43:11 PM UTC+3, Jonathan Eskew wrote: >> >> >> >> On Sunday, June 26, 2016 at 1:32:37 PM UTC-7, Christopher Pitt wrote: >>> >>> Stream implementation is definitely out of scope for FIG, it has nothing >>>> to do with this topic. >>> >>> >>> It is of particular interest to the async interoperability work going >>> on. Perhaps we'll get a specification/implementation out of there... >>> >> >> PSR-7 defines an interface for streams, and Guzzle offers a suite of >> implementations (as detailed at >> https://github.com/guzzle/psr7#stream-implementation). I'd say that the >> variety of stream implementations is one of the reasons someone would opt >> to use Guzzle's PSR-7 library instead of another, so it seems to directly >> answer the original poster's question. Not sure how it is off topic. >> > -- 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 php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/da5d38ad-2073-428b-b56e-468277f504e5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
