Re: RFC: Server-Side Request and Response Objects (v2)

Hi Rowan, > Why not hope that ReactPHP and others will want to use this object, > precisely because it avoids them having to roll their own implementations > of things? Like I said earlier: if React ends up wanting to use ext/request, with its tradeoffs, of course I would think that's great. But if they want to keep using what they have already, with its own tradeoffs, that's great too. > If somebody really wanted to use the parser without the rest of the object, > they could trivially wrap it in a function: > > function parse_multipart_form_data($content) { > $request = new ServerRequest([], $content); > return [ 'input' => $request->input, 'uploads' => > $request->uploads ]; > } This is very similar to what I'm saying: to use your phrasing, I opine it is better to "trivially wrap" the existing PHP functionality as part of a separate RFC, rather than try to embed it in ServerRequest (exposed or otherwise). To reiterate what I've said before: this RFC is a relatively conservative one. The vision around it is to stay pretty close to PHP as-it-is, and to incorporate those things from the researched implementations that show up over and over again. I know that does not lead quickly toward (what I surmise is) your vision of overhauling how PHP presents global state, but an overhaul of that kind is just not what this RFC aims to do. -- Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php