I'm sorry for these typos, I have to read my own message several times before posting.
On Monday, June 27, 2016 at 10:27:40 PM UTC+3, Daniel Plainview wrote: > > > PHP provides a DateTimeInterface and multiple implementations thereof, > so some programmers *do* want different implementations of DateTime > > That's not true. > PHP provides DateTimeInterface as a *hack*, because DateTime has a huge > design mistake and can't be fixed without breaking BC: > https://derickrethans.nl/immutable-datetime.html > You also cannot implement your own implementation of > the DateTimeInterface, because it's not real interface (feel free to try). > I repeat, it's just a hack for making possible to typing against both > implementations, but mutable DateTime was a mistake. > > > Streams are defined as a big part of PSR-7, so I'm not sure why they > shouldn't matter to an implementing library. > > I can't understand your point. As I said, I having nothing against > different stream implementations. > > > but Symfony's HttpFoundation provided a few subclasses of Response for > common use cases (like BinaryFileResponse, JsonResponse, and > RedirectResponse) > > This is just syntactic sugar. You always can replace it with middleware. > > On Monday, June 27, 2016 at 10:19:21 PM UTC+3, Jonathan Eskew wrote: >> >> 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/39895d1d-f34e-4f12-a38c-8ae40086e92e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
