Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108439
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
Date: Mon, 10 Feb 2020 12:32:42 -0500
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <5DEE5A6E-2587-432D-9651-320DF42A7732@newclarity.net>
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
To: "Paul M. Jones" <pmjones@pmjones.io>
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: mike@newclarity.net (Mike Schinkel)

> On Feb 10, 2020, at 11:18 AM, Paul M. Jones <pmjones@pmjones.io> =
wrote:
>=20
> Hi Internals,
>=20
> After a couple of years of incubation, I am happy to offer a second =
version of this RFC:
>=20
>  https://wiki.php.net/rfc/request_response
>=20
> It proposes an object-oriented approach around request and response =
functionality already existing in PHP, in order to reduce the =
global-state problems that come with superglobals and the various =
response-related functions.
>=20
> The SQLite "about" page says, "Think of SQLite not as a replacement =
for Oracle but as a replacement for fopen()." =
<https://www.sqlite.org/about.html>  Likewise, think of this RFC not as =
a replacement for HttpFoundation or PSR-7, or as a model of HTTP =
messages, but as an object-oriented alternative to superglobals, =
header(), setcookie(), setrawcookie(), and so on.
>=20
> Thanks in advance for your time and consideration while evaluating it.

I like this, a lot.=20

Having a language _standard_ approach means that I could depend on it =
existing and that all (new) userland code I might want to incorporate =
into a project would be compatible rather than the current state of 100! =
different incompatible implementations across frameworks. =20

I had numerous questions and concerns, but after reading through the RFC =
and the associated links I think you addressed most of them.

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?  And that there is no global buffer but instead the application =
would have to manage using a shared $response on its own because each =
instance of $response has it's own buffer and can be sent at any time =
into the existing output "stream?"

Regarding ServerRequest I saw the comment about using a factory instead =
of creating an instance and your reason for not going that route. 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 =3D new ServerRequest();
$request->initialize();
// OR
$request->initialize([
    '_SERVER' =3D> [
        'foo' =3D> '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 =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();

I would also suggest considering to add get(), post(), request(), =
cookie(), server() and end() methods to ServerRequest that would =
incorporate the functionality of filter_input().  Otherwise we have to =
bypass the objects to get filtering.

In general I think this would definitely be a nice enhancement to PHP, =
IMO.  It would be great to be able to deprecate use of $GLOBALS, etc. =
with a language _standard_ approach, and flag their use as problematic =
in any of our code.=20

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.)

Thanks in advance for considering.

-Mike=