Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108689
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: <f58eea0a-6d71-be57-c0b8-abc4321cdb38@gmail.com>
Date: Wed, 19 Feb 2020 14:21:46 -0600
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <1BF3D29A-04C6-4A82-9216-EAE991A38916@pmjones.io>
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
 <CANUQDCiP31aEqULqeGpN66ESHarKxWuXgQt_CqWeCLZc+1L-fA@mail.gmail.com>
 <5904137.fSVIMsojiJ@mcmic-probook>
 <CDBA02D0-07E1-4723-947C-22B403E650C0@pmjones.io>
 <CA+hqhpcOqCqXuOh3bWavJ+pZ5VVhekUO9LkKgd9c+b98VVnZSA@mail.gmail.com>
 <CAG9XoMRm2Nqjg3UbCc5=1_8m2W7qf8QRoSVk6d_qENJCKE1=9A@mail.gmail.com>
 <fcf43463-f9f7-4235-a84b-658074772ed7@www.fastmail.com>
 <3DDBFBA4-8D3A-46C5-9A10-B093A5E2386B@pmjones.io>
 <54493258-B52E-442A-A11D-82E1D4C7DE5E@gmail.com>
 <8264F6CF-AD55-41E2-9F5A-DAE8942E2B79@pmjones.io>
 <f58eea0a-6d71-be57-c0b8-abc4321cdb38@gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: pmjones@pmjones.io ("Paul M. Jones")

Hi Rowan,

Again, thanks for your time and effort in evaluating this proposal.


> On Feb 18, 2020, at 14:21, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> - What's the sales pitch - what do YOU think is great about these =
classes?
>=20
> ...
>=20
> Sell it to me! :)

I don't do sales; occasionally I can present a good narrative. Maybe the =
narrative below will help.


> - When working out the details, what code should we be picturing using =
the new classes?

Not to be flippant, but: request-reading and response-writing code?


>> ...a built-in OO-ish request/response object set...
>=20
> "OO-ish" is a wise choice of words here. One of the reasons I'm not =
terribly keen on this proposal - particularly the request half - is that =
I'm a bit of an OO purist.

Heh -- yes, I am aware of the impurities (both perceived and actual) of =
ServerRequest. ;-)

However ...


> The lack of behaviour also makes it less useful to people writing =
their own request and response objects: if I have a copy of $_POST and =
want to put it in my own object property, why would I first pass it to a =
ServerRequest object, and then get it straight back out again, if the =
object isn't helping me do anything with that data?

... in this case, ServerRequest does quite a bit that is easy to take =
for granted, since it does so quickly and quietly. Among other things:

1. It "bundles" several related pieces of data; not just $_POST but =
$_GET, $_COOKIES, etc., so they can be carried around together.

2. It separates that data from global state.

3. It parses some of that data into commonly-needed structures (eg. the =
`$accept*` arrays).

4. Its copies of that data are read-only and immutable, so that once set =
they cannot be modified at a distance when shared around; this keeps =
them stable throughout the system.

So while it is true that ServerRequest "lacks behavior" in the sense =
that it doesn't "do" anything *after* construction, but it also true =
that it does quite a bit *at* construction.

Indeed, the vast majority of uses (in practice) for a ServerRequest type =
of object are "reading" or "getter" uses. There is comparatively little =
need to write to a ServerRequest instance. Almost all of the time, all =
you need is to read from it post-construction.

Further, there's no need to optimize for calculation-on-demand, since =
the calculations are so speedy in the first place. And since it will =
happen only once in the request lifespan, you might as well build all =
the properties at construction-time. At that point, getter-type methods =
are just returning what has already been calculated. And at *that* =
point, read-only properties do the trick quite nicely.

For the comparatively-rare (but still necessary) times when you need to =
write to a ServerRequest type of object, it is open to extension in =
userland for those application-specific cases.


>> ...that does pretty much just what PHP itself already does...
>=20
> As you say elsewhere, this is useful for helping people migrate to it. =
The flipside of that is that it ties us into past decisions, rather than =
evaluating whether those decisions are still what we want.

Your comment jogged my memory of an older conversation, =
<https://externals.io/message/100087>, in which you figure prominently, =
and in which I pointed out the existence of the prior version of this =
RFC. Many things there are reminiscent here:

- Should superglobals be made read-only?
- Should superglobals be made into objects instead of arrays?
- Should superglobals be replaced entirely with some new system?
- Are additional superglobals needed?
- Should there be a layer of indirection between superglobals and their =
use in applications?

This RFC answers from (if you'll pardon the word) a conservative =
position: no, no, no, maybe, and yes. In the last case, this RFC can be =
construed to provide ServerRequest as that layer of indirection for some =
of the superglobals.


> The approach in providing both $files and $uploads arrays is a good =
compromise - provide the new better way, but also an easy-to-migrate =
way. I'd love to see them named more distinctly, though, maybe even =
calling one of them "legacy". I'd probably also make them methods so =
that the data can be stored once (in the new format) and re-formatted on =
demand (again, objects as behaviour rather than data).

I appreciate that concession on your part, and thanks for saying.

I think $uploads is a pretty distinct name, while being clearly related =
to files. And, as I mentioned earlier, the cost of reformatting the =
$_FILES structure to $uploads is so low that it might as well occur at =
construction time, instead of adding a method to calculate-and-retain =
the reformatted structure.


>> ...easing their transition away from global state
>=20
> This I find less convincing. To quote from further down the e-mail, I =
wrote:
>=20
>>> ...you can do almost as much in that direction as the RFC by writing =
"$get=3D$_GET; unset($_GET);" The hard problem is that the entry point =
for a request is in global scope, not a main() or handleRequest() =
function.
>=20
> and you replied:
>=20
>> Another "hard" problem is carrying those values around in the system =
once they are decoupled from global state; the objects in this RFC =
purport to do so.
>=20
> If all the object does is "carry around" a copy of the superglobal =
arrays, I can write it in about a dozen lines of code.

I answered this above, but to reiterate: "carrying around" is *one* =
thing ServerRequest does, but not *all* it does.


> Again, the response object is more powerful in this regard, because we =
can't currently pass around a list of prepared cookies and trivially =
output it to the client.
>=20
> Along the lines of my previous message about decoupling concerns, I =
would personally like the response parts of the proposal split out and =
re-cast as a kind of "response buffer".

I admit I considered this. However, it makes more sense to me in terms =
of symmetry/complementarity, and in terms of "what we need on a daily =
basis", to provide both the request object and the response object =
together.


>> I had considered mentioning the dual OO+procedural APIs of mysqli, =
date, etc. but it seemed too much in an already-long RFC; I'm glad you =
brought it up, as I did have it in mind.
>=20
> This is an interesting comparison to consider. Just as those =
extensions have procedural options for people who can't stand objects, =
the current proposal has objects for people who like "OO-ish".

Yes, I think so too.


>>> Introducing these objects as part of a new calling convention for =
PHP scripts would definitely add value, and make them a true replacement =
for the superglobals, but that would be a very different RFC.
>>=20
>> That does seem rather ambitious. If you feel that's a valuable thing =
to add to PHP, perhaps it could be part of a future RFC, maybe even one =
that uses the objects in this RFC as a starting point.
>=20
> One of the things I don't like about the current proposal is that it's =
modelled so closely around the current superglobals that I fear it would =
actually be *harder* to replace them.

Maybe? I can similarly imagine that if new-and-different superglobals =
appear, the ServerRequest object can evolve to contain and/or translate =
between them.


> Parsing a request body from an arbitrary source into arrays that match =
the structure of $_POST and $_FILES would be a really useful feature.

Yes, although one can do at least the $_POST portion with ServerRequest =
as it is now. For example, a naive userland factory might do this:

    class ServerRequestFactory
    {
        public function new(array $globals, ?string $content =3D null) : =
ServerRequest
        {
            if ($this->isJson($globals['_SERVER']['CONTENT_TYPE'] ?? '') =
{
                $globals['_POST'] =3D json_decode(
                    $content ?? file_get_contents('php://input'),
                    true
                );
            }

            return new ServerRequest($globals, $content);
        }

        protected function isJson(string $contentType) : bool
        {
            return $contentType =3D=3D=3D 'application/json'
                || substr($contentType, -5) =3D=3D=3D '+json';
        }
    }

Call `$request =3D (new ServerRequestFactory())->new();` and voila: the =
equivalent of `$_POST`, populated from JSON content, stored as =
$request->input.


> I also really want to see the day when I never have to interact with =
$_SERVER again. Other than renaming it, this object's design makes that =
less likely, not more.
>=20
> Imagine if in future we're able to redesign the internals so that =
there is a dedicated and reliable field for the requested URL; the =
current object doesn't have anywhere we can put that. If we add it =
later, it will be too late, code will be written that passes around =
ServerRequest objects, but relies on the full array of CGI variables to =
reconstruct the URL.
>=20
> If this object took a more opinionated view of what behaviour to =
encapsulate, we could simply hide the "server" array completely. Common =
use cases would be exposed via methods, and rarer use cases would have =
to be added in userland with their own copy of $_SERVER. Then my dream =
of deprecating $_SERVER could mean something other than moving it into =
an object.

Yes, the internals thread I pointed to earlier makes that clear.  And =
though I understand where you're coming from, especially regarding "a =
dedicated and reliable field for the requested URL", this RFC does not =
have that kind of ambition, nor do I expect it to in the future.

This proposal is satisfied to take only a smaller series of steps to =
ease a more limited set of problems, rather than revise major and =
wide-ranging elements of PHP overall. I presume you will find that =
unsatisfactory, but, well, there it is.


--=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