I have kept out of this for a while now as I have had life things that felt more important to deal with, but I have to chime in again for my own sanity at least.
Please understand that as an outsider to this group, and someone who has not been involved in the process for this proposal at all, it just does not make sense. When it was a DelegateInterface, and even now as a RequestHandlerInterface, it does not state what it is doing. Code should state the purpose it has, and 'handling a request' is not the purpose of an implementor of this interface; at least not as far as I can see. It is expected to return a response, so wouldn't a name describing that be more fitting? When I first read the name change, I assumed that it meant that any class I write (like a route class) is supposed to implement this to be used in a middleware, that I would have to choose for each middleware which class to use to create a response object. I hope that I am wrong and think that is the case. That got me thinking then, well, what is it? What is it supposed to do? How do I implement something like that? Basically the same questions I've asked of this proposal from the start. I know you have all been round the houses on this, but I have to tell you that good code is supposed to be intuitive. Good interfaces should be too. This proposal still confuses me since the first day I saw it. The only decent way to explain this I fear, is to implement it, and then if there is an implementation, why would anyone do it another way? Ambiguous design like this is a big problem in software, and I feel that this proposal is making this a reality for the FIG. On Tuesday, 5 December 2017 17:49:53 UTC, Matthew Weier O'Phinney wrote: > > As of today, we formally begin the REVIEW phase of the proposed PSR-15 > (HTTP Server Request Handlers) specification. The proposed > specification is in the fig-standards repository at the following > locations: > > - Specification: > > https://github.com/php-fig/fig-standards/blob/52a479b55f5c235ab44aed2254de7ef1f085982e/proposed/http-handlers/request-handlers.md > > - Metadocument: > > https://github.com/php-fig/fig-standards/blob/52a479b55f5c235ab44aed2254de7ef1f085982e/proposed/http-handlers/request-handlers-meta.md > > > During the review phase, acceptable changes to the specification > included wording, typographical fixes, and clarifications. If you feel > major changes are necessary, please bring your arguments to the list > under this thread. Woody Gilk, the Editor of the specification, will > be final arbiter on what changes we will include. If any major changes > are considered, we will return to the draft phase. > > The review period will end no sooner than 1 January 2017 at 11:59pm. > At that time, if the working group can demonstrate two viable trial > implementations, and no need for major changes, I will call for an > Acceptance Vote. > > -- > Matthew Weier O'Phinney > mweiero...@gmail.com <javascript:> > 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/7d1498bf-cdb2-4e96-b8c9-c735a74e05e4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
