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
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

Reply via email to