Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108650
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: <54493258-B52E-442A-A11D-82E1D4C7DE5E@gmail.com>
Date: Mon, 17 Feb 2020 09:55:07 -0600
Cc: Rowan Tommins <rowan.collins@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-ID: <8264F6CF-AD55-41E2-9F5A-DAE8942E2B79@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>
To: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: pmjones@pmjones.io ("Paul M. Jones")

Hi Rowan,

I apologize in advance for the length of this email. I hate reading =
walls-of-text, but the answers are necessarily long. I have tried to =
break it up into bullets where possible for easier reading.


> On Feb 15, 2020, at 19:37, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> On 15 February 2020 20:10:30 GMT+00:00, "Paul M. Jones" =
<pmjones@pmjones.io> wrote:
>=20
>> Hi all,
>>=20
>>> On Feb 15, 2020, at 02:01, Larry Garfield <larry@garfieldtech.com>
>>> wrote:
>>>=20
>>> ... is this proposal intended to supplant HttpFoundation and PSR-7
>>> ... ?
>>=20
>> This is question is answered in the RFC introduction
>=20
> You've cut Larry's question in half there, and in doing so made it =
seem like a repeat, when it is not. The second half of the sentence is =
this:
>=20
>> ...or to become a common underpinning that both of them wrap, or to =
be a third cohabitating implementation in the ecosystem?
>=20
> I haven't seen you answer that part yet: do you expect existing =
userland libraries to migrate from wrapping $_GET etc to using these =
built-in wrappers. If so, what benefit does it bring those libraries? If =
not, who is its intended audience?

I really did think the answers to these were obvious, or =
easily-inferred, but obviously I was wrong. I will attempt to expand.

Q: "Do you expect existing userland libraries to migrate ... ?"

A: To be clear, I don't *expect* anything from existing published =
library authors; however ...

  - I *suspect* that some will choose to ignore this extension,

  - that others will decorate or extend it,

  - and that still others may find their own work so close to this =
extension that they migrate over to it entirely.

Further ...

  - I suspect that developers of in-house unpublished request/response =
objects may find this useful for their own purposes,

  - and that developers who are using $_GET, header(), etc. will be =
pleased to find an OO-ish system that operates much like PHP itself =
already does, easing their transition away from global state.

Finally ...

  - I suspect that some *consumers* of existing libraries will feel this =
extension is not their preferred way of working, and continue on with =
whatever libraries they already use,

  - while other consumers of those libraries will prefer this extension =
in their place.

On reading over this, I suppose I do have an "expectation" of library =
authors and their consumers: that as good engineers they will evaluate =
this extension in reference to their own circumstances, and choose to =
use it (or not use it) based on the tradeoffs they find for their =
situation.


Q: "What benefit does it bring those libraries?"

A: Whatever benefits their authors happen to see in it. For myself, and =
as noted by Jan Schneider and others, those benefits center around =
having a built-in OO-ish request/response object set that does pretty =
much just what PHP itself already does, and that is well-suited to our =
daily work, without needing to incorporate comparatively large libraries =
into our projects for what we consider to be relatively simple purposes =
-- those purposes being "reading the request inputs" and "sending the =
response outputs".


Q: "Who is its intended audience?"

A: I always thought of the "intended audience" as the much the same as =
for any RFC: that is, developers working on a website who want PHP to =
provide a reasonable set of functionality for doing so, request/response =
objects being part of that set in a language as closely related to the =
web as PHP is.

(As a fun side note: for all its apparent simplicity, this is an =
extraordinary question. Unless I have missed something, I don't recall =
it being asked directly of any RFC before. A Google search against =
wiki.php.net and externals.io reveals a double-handful of results on the =
terms "intended audience" and "target audience", but the only even =
indirect question about it on an RFC is in relation to the JIT, here: =
<https://externals.io/message/103903#103995> -- and it's by you. :-)


* * *

Rowan, you quoted Larry asking if this extension was ...

>> to be a third cohabitating implementation in the ecosystem?

... that is, third after HttpFoundation and PSR-7.

(By way of preamble, and to reiterate what I've said before: I would =
prefer to discuss this RFC on its own terms. But, as you and others want =
some discussion in context of other projects, I will do so. My apologies =
if I sound negative or critical toward those projects.)

It turns out the question is kind of a funny way of describing the =
situation, in that PSR-7 is not an implementation of anything. (Full =
disclosure: I was a sponsor on the PSR-7 proposal.)

PSR-7 is instead a set of interfaces; that is, they "are abstractions =
around HTTP messages and the elements composing them."  =
<https://www.php-fig.org/psr/psr-7/>  The meta document notes, "the goal =
of this proposal is not to obsolete the current interfaces utilized by =
existing PHP libraries. This proposal is aimed at interoperability =
between PHP packages for the purpose of describing HTTP messages." =
<https://www.php-fig.org/psr/psr-7/meta/>

So, to refer to PSR-7 as a "cohabiting implementation" is a bit mistaken =
(but a very easy mistake to make -- I imagine I have made it myself =
occasionally).

If we are going to talk about implementations in an ecosystem, then, =
there are at least four for PSR-7:

- Cake
- Guzzle
- Slim
- Zend/Laminas

There are others as well, with varying ranges of adoption; and, as PSR-7 =
is an interoperability specification, I predict there will be more =
implementations later.

The above implementations are partially but not always fully =
interchangeable; while they adhere to the PSR-7 method interfaces, they =
each have their own behavioral idiosyncrasies. In some cases they offer =
additional methods and behaviors that the others do not have. (This is =
not a criticism, merely an observation.)

Thus, if one wishes to speak in terms of "cohabiting implementations", =
ext/request would have to be counted as one of at least six (i.e., =
itself, HttpFoundation, and the above four).

I don't know if that strengthens or weakens the ext/request case, but it =
does help to clarify the world in which it exists.

* * *

Rowan, you wrote:

> You said previously:
>=20
>> PDO did not (to my knowledge) "add capabilities which cannot exist in =
userland or cannot exist in a reasonably performant way".
>=20
> I think this is a misjudgement, and a relevant one. PDO didn't take =
functionality that existed purely in userland and migrate it to an =
extension; it took functionality that was scattered across a dozen =
different vendor-specific extensions with different naming and calling =
conventions, and centralised it into one more-or-less consistent =
interface. In doing so, it made (or at least tried to make) life easier =
both for database vendors, who can provide a PDO driver and fit into the =
ecosystem, and library developers, who can use PDO as a base and have =
less vendor-specific code.

That is one valid way of looking at it; but then, on exactly the same =
terms, it is likewise valid to say that AdoDB "took functionality that =
was scattered across a dozen different vendor-specific extensions with =
different naming and calling conventions, and centralised it into one =
more-or-less consistent interface." So did PEAR DB, Metabase, MDB, and =
so on. PDO did it as an extension, instead of in userland, but the goals =
and outcomes noted were identical.

I find this more confirmatory than not regarding my earlier =
counter-argument; i.e., that (in hindsight) objections based on the =
existence and availability of userland projects would not themselves =
have been a barrier to PDO, and so should not themselves be a barrier to =
this RFC.


> Your other examples - date, phar, and session - took common problems =
that were possible to solve in userland but tricky to solve well, and =
provided a standard out-of-the-box implementation.
>=20
> We already have a unified out-of-the-box implementation for the =
problem "get data out of HTTP request", in the form of superglobals, so =
neither comparison seems apt.

Perhaps; working by analogy is always a difficult and imperfect task.


> A better comparison might be to features which have been reimplemented =
multiple times, to fix fundamental problems. A recent example is =
__serialize, but interestingly $_GET et al are themselves the third =
implementation of the feature, after "register globals" and the $HTTP_* =
arrays.
>=20
> As far as I can see, the RFC mentions two things it fixes about the =
current implementation:
>=20
> - The current implementation is not OO. That's not really surprising, =
since PHP is not a purely OO language, and treats OO as a matter of =
style - to the extent of providing hybrid object-procedural APIs like =
date and mysqli.

"As a matter of style" is a good line! In support of that line, this RFC =
does not seek to remove $_GET and the response-related functions, but =
rather to provide an additional OO-ish approach that honors the existing =
(as you say, the third-time's-the-charm) language-level approaches.

FWIW, 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.


> - The current implementation is based on global state. This is =
definitely something that would be good to fix, but 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

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.


> 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.

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.


* * *

Again, my apologies for the wall-of-text. Please let me know if you find =
those answers are sufficient or not.


--=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