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
[email protected]
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
