Hello,
The one thing in PSR-7 still bothers me: do different implementations truly
exist?
Or in other words: how these implementations may differ in terms of
behaviour?
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.
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.
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)
— 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.
If you compare existing implementations, they looks suspiciously similar.
Let's compare ResponseInterface::withoutHeader() from ZF and from Guzzle:
// ZF
public function withoutHeader($header)
{
if (! $this->hasHeader($header)) {
return clone $this;
}
$normalized = strtolower($header);
$original = $this->headerNames[$normalized];
$new = clone $this;
unset($new->headers[$original], $new->headerNames[$normalized]);
return $new;
}
// Guzzle
public function withoutHeader($header)
{
$normalized = strtolower($header);
if (!isset($this->headerNames[$normalized])) {
return $this;
}
$header = $this->headerNames[$normalized];
$new = clone $this;
unset($new->headers[$header], $new->headerNames[$normalized]);
return $new;
}
Oh my god, someone copy pasted code from another implementation?
Probably, yes.
Probably, no.
Because it's hard to imagine *different* implementation.
They will probably differ in terms of variable names, some equivalent
expressions, etc...
— Implementations may depend on some low-level details like PCRE extension
(preg_match), etc.
That's true. However, some dependencies are so widespread, so you can
ignore this fact.
---
After all, this new PSR with factories for HTTP-messages wouldn't be needed.
It would make impossible to have incompatible implementations.
And it makes many other things much simpler.
Do I miss something?
--
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/5f562c68-c4f3-4de9-a1d8-ecfdd742c3db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
