I don't like "frame" as it feels elitist to me. Canvas 10,000 PHP developers and ask them if they can guess what a "Frame" would be used for in a PHP application. I don't think you'll get 70% correct answers. To my mind, it makes it harder to understand and hence creates a barrier.
As I've said before, I'd prefer not to have an interface at all, but if you must have one, then please try to be inclusive with us non-computer scientists. Given that you want an interface, I like `DispatcherInterface` personally as that's what the object does. The docblock for `next()` in the proposed document even states: "Dispatch the next available middleware and return the response". Regards, Rob... > On 17 Aug 2016, at 22:54, Stefano Torresi <[email protected]> wrote: > > 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? -- 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/B504FEC6-CDE7-42F2-8235-C3B47E208E65%40akrabat.com. For more options, visit https://groups.google.com/d/optout.
