In my humble opinion, there is nothing wrong with "FrameInterface::next()": I think it communicates intent and context by suggesting the analogy with call stack frames.
"MiddlewareDelegateInterface::process()" on the other hand, while technically correct, is in my opinion too generic and ambiguous: it could mean a lot of things other than "the rest of the middleware stack". On a side note, I personally find Delegate the most generic and ambiguous composition pattern ever conceived. Would an explanation of the rationale behind the "frame" term in the metadocs be satisfactory for those who were surprised by its choice? Il giorno mer 17 ago 2016 alle ore 18:47 Matthieu Napoli < matth...@mnapoli.fr> ha scritto: > Thanks a lot for the detailed response Matthew. > > If you already discussed that then sorry for wasting your time (and others > too), your answer sounds valid to me I wasn't expecting such a high level > of backward compatibility with existing systems. > > To avoid repeating that discussion in a few months I have taken the > liberty of picking a few of your sentences and write a summary of that in > the META document: https://github.com/php-fig/fig-standards/pull/807 > > Now it seems the only topic worth discussing is the name? Rasmus you > suggested `DelegateInterface` instead of `FrameInterface`, that sounds like > an improvement to me (I have nothing better to suggest), what do others > think? > > Le mercredi 17 août 2016 16:05:57 UTC+2, Matthew Weier O'Phinney a écrit : >> >> On Sun, Aug 14, 2016 at 12:47 PM, Larry Garfield <la...@garfieldtech.com> >> 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 >> > mweiero...@gmail.com >> 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/8ea2fb90-2d69-484c-9b53-bec40722a17b%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/8ea2fb90-2d69-484c-9b53-bec40722a17b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAFojS1sbB%2Bags6VzYERsrtLe256t%2BooXiLEf2gcEOrDu3FrWHw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
