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
