On Sun, Aug 14, 2016 at 12:47 PM, Larry Garfield <[email protected]> wrote:
> On 08/14/2016 12:32 PM, Matthieu Napoli wrote:
>
> so I wonder why we aren't using __invoke in that interface too
>
> That's a very good idea, it might be a good middle ground:
>
>
> interface Next
>
> {
>
> public function __invoke(ServerRequestInterface $request) :
> ResponseInterface;
>
> }
>
>
> I believe the argument MWOP made in the past is that many existing
> middleware systems already use __invoke(), so PSR-15 using __invoke() as
> well would make bridge code harder. A separate method makes having an
> object that just calls the method from an existing __invoke() (or vice
> versa) trivial.
That was indeed the argument.
Since many (most) existing middleware systems already use either
callables or a class/interface that implements `__invoke()` for the
`$next` argument, specifying the interface within this PSR to define
`__invoke()` has the potential to make it completely incompatible with
these existing systems without major changes.
As an example, consider a middleware that targets this PSR, but is
dropped into Expressive or Slim, and then calls on $next:
return $next($request);
In each of these cases, a second argument *is required currently*,
which means that this invocation will result in a fatal error.
If we instead use another method entirely, the above becomes something like:
return $frame->next($request); // or:
return $delegate->next($request); // or:
return $delegate->process($request); // etc.
As a result, these existing libraries can implement the interface
without breaking backwards compatibility:
class Next implements DelegateInterface
{
public function __invoke(ServerRequestInterface $request,
ResponseInterface $response)
{
// ...
}
public function next(ServerRequestInterface $request)
{
// ...
}
}
allowing them to mix-and-match middleware written for the previous
version with middleware targeting this PSR. Since the new interface
method only indicates one required argument, the implementation can
even pass the response to ensure backwards compatibility, and provide
tools for scanning middleware to warn about implementations that need
to be updated.
While I appreciate that we want to standardize on what is already
being done, the fact that the calling patterns of existing middleware
dispatchers vary currently means that having a discrete, unique method
ensures greater compatibility once the specification is finalized,
easing the way to adoption by existing libraries.
--
Matthew Weier O'Phinney
[email protected]
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/CAJp_myURSqsDawvkHMzepuyWMG5v0uoY5_N6Q8ggZ4uUsQX8vQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
