Re: [RFC][Discussion] ServerRequest and ServerResponse objects

On 09/01/2017 15:43, Paul Jones wrote:

Either way, I think we can see from reactions here since then (and elsewhere) that there is some level of positive interest in the RFC as presented, as well as some healthy technical questioning. I'm happy to hear both.

I think it's easy when you're proud of what you've got to feel like the point of discussion is to defend your proposal, and persuade others that it doesn't need to change; but at its best, it's about understanding how to refine and reshape your idea. So perhaps the surprise is less that you're going ahead with the proposal, and more with how little it's changed based on that initial feedback. In particular, the RFC still lacks an explanation of where this fits in the ecosystem alongside pecl_http and PSR-7, which aren't even mentioned once in the RFC, the extension's readme, or your blog post.

I get why that would be. It's really an outgrowth of the asymmetry that already exists in PHP: $_GET, $_POST, et al. are properties representing the request, whereas header(), setcookie(), et al. are all functions for sending a response. Having said that, practical use of ServerRequest the intervening time has given rise to some methods for application-related convenience.

This all seems rather arbitrary to me. You're creating a new API, presumably because you feel the existing way of accessing these things is inadequate; yet you take as your starting point being as close to the legacy APIs as possible. Then you add some genuinely new functionality, but without any stated goal or philosophy regarding what should be added and what left out. The most important thing, though, is that you don't need an RFC to pass for people to start using this - you've already listed it on PECL, so if you think it's ready, and has a use case, you can mark it final, and people can start using it right away. The bar for inclusion in core is necessarily higher, and comes at a cost to you as well - you lose control of when the code is released, and even what direction future development will take. I think there is the germ of a useful project in here, but if you want it to become the official PHP answer to some question, you need to think more about what that question is, and how to make it the very best answer. Regards, -- Rowan Collins [IMSoP]