The reason that StackInterface exists as a "MAY" recommendation is because it illustrates the requirement that stacks must be aware of the type hint of the middleware being added to the stack [1]. If the stack ONLY accepts client middleware, it MUST type hint against ClientMiddlewareInterface. If it accepts both server and client middleware, it MUST type hint against MiddlewareInterface.
Now it could certainly be argued that having the StackInterface is out of scope for the spec and I wouldn't disagree. However, any removal [2] should be accompanied by an update to the middleware meta document to describe how the type hints should be used. Personally, I find having code examples more useful than words, which is why I added the StackInterface as a "MAY" recommendation. With regard to having the methods withMiddleware() and withoutMiddleware() be immutable, I think this is in line with PSR-7. [1]: https://groups.google.com/d/msg/php-fig/sYecuqdYIkY/PPVL2RDqEgAJ [2]: https://github.com/php-fig/fig-standards/pull/803 -- Woody Gilk http://about.me/shadowhand On Mon, Aug 15, 2016 at 2:08 AM, Alexandru Pătrănescu <dreal...@gmail.com> wrote: > +1 for removal. > There is really no reason to have it. > > The methods for creating the stack are not going to be used against the > interface because each library will have it's own way of using it's > implementation. > What remains is the process method that I think is also in the same > position: you know the implementing class when you call it. > > Regards, > Alex > > On Sunday, August 14, 2016 at 8:13:19 PM UTC+3, Matthieu Napoli wrote: >> >> Sorry for bringing that topic up again but I'll make it clearer: >> >> I think the StackInterface should be removed. >> >> - I don't see what it has to do with PSR-15 (interoperability for invoking >> middlewares)? >> - even if it was a separate PSR, I don't see the problem it is solving >> (and the META document doesn't help) >> - I think the interface itself is very limiting and should be improved >> (but again, I don't think it should exist at all so…) >> >> Do we have any reason to keep it, or should we remove it? > > -- > 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/b9021564-07b1-44fa-ae87-4afb36c6a211%40googlegroups.com. > > 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/CAGOJM6%2BVjTZzeXn6qfoAis1wgCq3_d8vei30G1X2RNiMQRe8sA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
