Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108507
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
In-Reply-To: <5DEE5A6E-2587-432D-9651-320DF42A7732@newclarity.net>
Date: Wed, 12 Feb 2020 06:47:31 -0600
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <A988787C-9EB6-4BF2-90DF-68F0D3BAC494@pmjones.io>
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
 <5DEE5A6E-2587-432D-9651-320DF42A7732@newclarity.net>
To: Mike Schinkel <mike@newclarity.net>
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: pmjones@pmjones.io ("Paul M. Jones")

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.
>=20
> $request =3D new ServerRequest();
> $request->initialize();
> // OR
> $request->initialize([
>    '_SERVER' =3D> [
>        'foo' =3D> 'bar',
>    ],
> ]);
>=20
> 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.
>=20
> $request =3D new ServerRequest();
> $request->get =3D [ 'foo' =3D> 'bar' ];
> $request->cookie =3D [ 'id' =3D> 123 ];
> $request->nv =3D $_ENV;
> $request->server =3D $_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 =3D new ServerRequest([
        '_GET' =3D> ['foo' =3D> 'bar'],
        '_COOKIE' =3D> ['id' =3D> 123],
        '_SERVER' =3D> $_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 =3D filter_input(INPUT_GET, 'foo', =
FILTER_SANITIZE_SPECIAL_CHARS);

... would easily become this:

    $foo =3D 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.


--=20
Paul M. Jones
pmjones@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