Hi Mike,
> I like this, a lot. ... In general I think this would definitely be a nice > enhancement to PHP, IMO. Thanks for saying! > I do have questions about ServerResponse. It is not clear how that interacts > with existing echo, header(), setcookie(), etc? You say it creates a buffer; > is $responseSender->send($response) effectively the same as having issued > regular echo, header(), setcookie(), etc. all at once? That's correct. ServerResponse stores the (mutable) state of the response; ServerResponseSender reads from the ServerResponse and calls header(), setcookie(), etc. with its values. > each instance of $response has it's own buffer and can be sent at any time That is also correct. > Regarding ServerRequest ... How about instead creating an empty mutable > object with the constructor and then a method with an optional array > parameter that adds the values and "locks" it to be mutable, i.e. > > $request = new ServerRequest(); > $request->initialize(); > // OR > $request->initialize([ > '_SERVER' => [ > 'foo' => 'bar', > ], > ]); > > With this approach someone could create a class that contains the > ServerRequest and build the object up to be anything they like which could be > useful for testing, i.e. > > $request = new ServerRequest(); > $request->get = [ 'foo' => 'bar' ]; > $request->cookie = [ 'id' => 123 ]; > $request->nv = $_ENV; > $request->server = $_SERVER; > $request->lock(); That is essentially what it does now; the difference is that you mimic the $GLOBALS array at construction time, and the instance locks automatically: $request = new ServerRequest([ '_GET' => ['foo' => 'bar'], '_COOKIE' => ['id' => 123], '_SERVER' => $_SERVER, ]); // $request is now locked The class that contains ServerRequest would then build up that array for the constructor. Do you feel that's close enough to what you're asking for? > I would also suggest considering to add get(), post(), request(), cookie(), > server() and end() methods to ServerRequest First, I'd have to decline adding request() (or $request) at all; my opinion is that one ought to be reading from $get, $post, $cookies, etc. specifically, not from a pool of those values. Second, if I understand you correctly, I much prefer the property access over the method getter; it just "looks and feels better": $request->get['foo'] vs $request->get()['foo']; Let me know if that makes sense to you or not. > incorporate the functionality of filter_input(). Otherwise we have to bypass > the objects to get filtering. I don't think you'd have to bypass the objects to get filtering; unless I am missing something, this ... $foo = filter_input(INPUT_GET, 'foo', FILTER_SANITIZE_SPECIAL_CHARS); ... would easily become this: $foo = filter_var($request->get['foo'], FILTER_SANITIZE_SPECIAL_CHARS); There might be behavioral nuances between the two, but the point is that you can still do filtering. > Would you not also add an option to generate a warning when using them for > those who want to deprecate their use in their own code (deprecating across > the board would be too extreme give how much CMS and framework code uses them > intimately.) That seems a bit much at this point. ;-) I hope that answers all your questions. -- Paul M. Jones pmjo...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php