Hi Mike,
Thanks for your continued evaluation of the RFC.
> Take a look at WordPress. It does a lot of "fixup" to $_SERVER` variables —
> to deal with badly implemented web servers — to ensure all known variables
> have a value and that the format of the value is consistent.
>
> ...
>
> Another option actually would be to allow changes to $_SERVER prior to
> instantiating ServerRequest() the first time.
Believe it or not, this RFC does make allowance for what you're describing, as
a result of requiring a $globals array as the first parameter. An
application-specific builder or factory can modify those $globals values as
desired, before instantiating ServerRequest with the modified values.
For example:
namespace App;
use ServerRequest;
class ServerRequestFactory
{
public function new(array $globals, ?string $content = null) :
ServerRequest
{
// do fixup to $globals['_SERVER'] ...
// ... then:
return new ServerRequest($globals, $content);
}
}
$request = (new \App\ServerRequestFactory())->new($GLOBALS);
I can easily imagine many ways to achieve the same end (i.e., modification of
the constructor arguments before instantiating ServerRequest).
Do you get where I'm coming from?
>> 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.
>
> That's definitely fair. I almost did not include request() in my suggestion
> but did because PHP has $_REQUEST.
Good enough. :-)
> Why a method is important is to support filters (I guess I assumed that was
> obvious but realize now it was not.) For example:
>
> $request->get('redirect', FILTER_SANITIZE_URL);
> $request->get('product_id', FILTER_SANITIZE_NUMBER_INT);
> $request->get('email', FILTER_SANITIZE_EMAIL);
>
> You could potentially even have scoped, easier to remember constants that can
> work with autocomplete:
>
> $request->get('redirect', ServerRequest::URL);
> $request->get('product_id', ServerRequest::INT);
> $request->get('email', ServerRequest::EMAIL);
[snip]
I do see what you mean. Even so, I think filtering is out-of-scope for this
RFC. Certainly I want to avoid adding methods to the ServerRequest class, which
as envisioned is a bag of values much the same way $_GET, $_POST, $_SERVER,
etc. are bags of values.
>>> 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. ;-)
>
> Really? Seems like this and some guard code is all it would take:
>
> ini_set( "disallow_superglobals", true);
Even if that's true (and I think that example masks some complexity) I must
maintain that it's out of scope for this RFC.
--
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
