I think it can be both. - A FrameInterface to be used when developing middleware. - A CallableFrame class that's wrapping the callable if you really want to call it in a simple way. Maybe sometimes it's worth to have a very simple final class also in the PSR along with interfaces.
For middleware developers the type safety will be a plus. Coming back to the name, I don't think FrameInterface is correct. If the method is *next()*, it could be something that is a collection and I can suggest *StackInterface* as a name. If the method is *run()*, it could be as simple as *NextFrameInterface* or just *NextInterface*. Regards, Alex On Fri, Jul 29, 2016 at 5:15 PM, Matthieu Napoli <matth...@mnapoli.fr> wrote: > Thanks Woody and Andrew for your answers, > > Type safety is a valid point. I'm all for type safety, however in this > case I'm not convinced it's worth it since it's just a callable that takes > a request and returns a response. It can't be any simpler (except maybe no > arguments), and sometimes simplicity can outweigh doing everything by the > book. > > I think it's worth considering, especially because if you look at existing > PSR-7 middlewares (expressive, slim, etc.), they use "callable $next". > > We have no idea how convenient it is (or not) to have that FrameInterface, > because currently nobody uses that. It's risky to standardize something > that nobody uses. > > TL/DR: reality trumps theory. > > Also I want to say how important the meta document is: it should contain > justification for everything that was decided in a PSR. > > Le vendredi 29 juillet 2016 15:42:41 UTC+2, Woody Gilk a écrit : >> >> On Fri, Jul 29, 2016 at 4:14 AM, Matthieu Napoli <matt...@mnapoli.fr> >> wrote: >> > >> > - FrameInterface doesn't represent any actual usage or existing >> middlewares today >> > - FrameInterface is more complex than `callable` >> >> >> From Anthony's blog post >> http://blog.ircmaxell.com/2016/05/all-about-middleware.html : >> >> > The fact that $next parameter is simply a callable also suffers from >> the same problem as above. It means that there's no longer any enforcement >> or ability to auto-complete or check types. >> > >> > Instead, $next should be a formal interface which would allow for type >> validation. >> >> I agree with his position. Having a formal interface ensures correct >> return type declarations in PHP 7. It shifts responsibility from the >> user having to know what is expected to be able to have a direct type >> hint that ensures accuracy. >> >> I recommend reading the entire article, it covers a lot why PSR-15 >> looks like it does, and why we need PSR-17. >> >> -- >> Woody Gilk >> http://about.me/shadowhand >> > -- > 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/84259821-f77f-4273-bdb7-b5f222629e62%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/84259821-f77f-4273-bdb7-b5f222629e62%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/CAAwdEzD4061LBOxQju4%3DGUjLuUgXsbnKu0e0jHBep4andR515g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
