> Guzzle has traditionally focused on client behavior, ... generator driven
streams; streams are its particular strength
Stream implementation is definitely out of scope for FIG, it has nothing to
do with this topic.
On Tuesday, June 21, 2016 at 6:59:13 AM UTC+3, Matthew Weier O'Phinney
wrote:
>
>
> On Jun 20, 2016 3:47 PM, "Daniel Plainview" <daniel...@gmail.com
> <javascript:>> wrote:
> >
> > Hello,
> >
> > The one thing in PSR-7 still bothers me: do different implementations
> truly exist?
>
> Of the top of my head: Diactoros, Guzzle, and Slim, and I've read of
> others working on additional implementations.
>
> > Or in other words: how these implementations may differ in terms of
> behaviour?
>
> Guzzle has traditionally focused on client behavior, and has optimizations
> around memory usage and generator driven streams; streams are its
> particular strength. Diactoros and Slim focus on server side details, with
> the former being a full, general purpose implementation, and the latter
> only implementing the server request and response (IIRC).
>
> league/uri provides an implementation of the UriInterface only, and is the
> most thorough implementation I've seen.
>
> Each is addressing particular elements that are of specific interest to
> their projects and intended use cases. The basic functionality is the same,
> but some features and approaches differ.
>
> > If they don't really exist, so why PSR-7 doesn't provide
> Request/Response classes?
> >
> > I'll try to bring my point through imaginary dialog.
> >
> > — You don't like interfaces? Program to an interface, not an
> implementation, Luke!
> >
> > PSR-7 provides the set of interfaces for HTTP-messages.
> > Yes, "program to an interface, not an implementation" is the first
> thought.
> > But sometimes different implementations don't make much sense.
> > Usually, one-to-one interfaces make no sense for value objects and
> entities.
> > If value object behaves differently in the same use cases, you probably
> work with different concepts.
>
> Where I'm seeing differentiation is around convenience features. As an
> example, specialized response types for json, html, XML, or even callable
> or iterator streams. Additionally, populating a server request typically
> requires a factory, and that detail will change based on whether you're
> using an SAPI or an async server.
>
> So, yes, there's definitely room for multiple implementations, even when
> programming to an interface.
>
> >
> > You always expect that DateTime('2000/12/31') + 1 day gives us
> DateTime('2001/01/01').
> > (if you work with Gregorian Calendar of course).
> > Behaviour must be the same in all possible implementations.
> >
> > However, in context of PSR-7, I see some cases when behaviour really may
> differ.
> > For example:
> > > UriInterface::getAuthority()
> > > If the port component is not set or is the standard port for the
> current
> > > scheme, it SHOULD NOT be included.
> >
> > It means that if I write
> > echo $uri->withScheme('http')->withPort(80)->getAuthority(), PHP_EOL;
> > it is possible to see different outputs: with port or without it.
> >
> > But the difference above is very minor.
> > I doubt someone chooses a library just because it hides port or not.
>
> You'd be surprised. :-)
>
> > I also tried to find another good examples of different behaviour, but I
> failed.
> >
> > — OK, what about existing libraries? Guzzle, HttpFoundation, etc. They
> can attach our shiny interface to existing VOs, as simple as that.
> >
> > Sounds nice in theory, but in practice is not as simple.
> > As far as I can see, most of popular libraries made new components to
> work with PSR-7.
> > For example:
> > https://github.com/zendframework/zend-http/tree/master/src vs
> https://github.com/zendframework/zend-diactoros
> > https://github.com/guzzle/psr7
> > https://github.com/symfony/psr-http-message-bridge (uses
> zend-diactoros, but anyway)
>
> This is not s valid comparison. Each of these projects predates psr-7, and
> adding psr-7 support cannot be done without breaking backwards
> compatibility. As such, they each have multiple supported versions,
> targeting the different APIs, or offer a parallel project, or are doing a
> stepped migration. You can't erase history, or force an upgrade overnight.
>
> > — PSR-FIG doesn't provide ready-to-use components anyway. We are not a
> framework.
> >
> > From my point of view, it sounds like excuse for comment-driven
> development.
> > You did great work with specification.
> > However, probably every statement from spec can be programmed very
> unambiguously.
>
> The key word here is "probably". Considering we have multiple
> implementations that do differ, and which are now generating errata due to
> differences observed, I disagree with your assertion.
>
> --
> Matthew Weier O'Phinney
> https://mwop.net
>
--
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/3f5fc2d0-6a9f-49b3-81a2-d1b97f72b64f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
