Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109002
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
In-Reply-To: <C3C15896-923D-4386-A991-329D0FCE7CC9@koalephant.com>
Date: Fri, 13 Mar 2020 09:55:45 -0500
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <102D234E-BC5D-42B2-ABC4-93980C1F76A4@pmjones.io>
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
 <D2321EFF-6D87-422A-BCC3-875820ADF8E2@pmjones.io>
 <C2A122BA-052B-4AFB-900E-93858BF50F7E@koalephant.com>
 <0B40E6E5-342F-4D81-9CAA-A0C0739A7718@pmjones.io>
 <C3C15896-923D-4386-A991-329D0FCE7CC9@koalephant.com>
To: Stephen Reay <php-lists@koalephant.com>
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: pmjones@pmjones.io ("Paul M. Jones")

Hi Stephen,

Good stuff. You have stepped through my & John's earlier thought-process =
in much the same way that led to the current naming.


> On Mar 13, 2020, at 09:23, Stephen Reay <php-lists@koalephant.com> =
wrote:
>=20
>> On 13 Mar 2020, at 20:39, Paul M. Jones <pmjones@pmjones.io> wrote:
>>=20
>> Do you have alternative suggestions or preferences on the names? Or, =
do you feel that "Request" and "Response" and "ResponseSender" (without =
any prefixes at all) would be sufficiently obvious?
>=20
> Hi Paul,
>=20
> TLDR: if you aren=E2=80=99t concerned about the concept of =
php-initiated outgoing HTTP requests, I think =
`HTTP{Request,Response,Buffer}` is quite clear in terms of naming. If =
you wanted to be more explicit about their purpose (and/or prevent =
possible confusion with either user land or potential future extensions =
handling outgoing requests), `IncomingHTTPRequest` and =
`OutgoingHTTPResponse` are very explicit, if a bit verbose.
>=20
> I think I did see that message, but I must admit I haven=E2=80=99t =
followed all the responses in the discussion.
>=20
> Personally I think `HTTP` makes a pretty obvious prefix (I=E2=80=99m =
not gonna get into a capitalisation debate), because these things are =
explicitly related to HTTP request and response messages.

I follow your reasoning. The main problem I see with "HTTP" (I won't =
argue capitalization either) is that I can guarantee you there will be a =
very vocal subset of users who will complain loudly and continuously =
that the objects do not model HTTP messages. I would prefer to pre-empt =
that, especially since it is true. ;-)

One other alternative John & I contemplated was =
`Web{Request,Response,ResponseSender}` -- do you think that might be a =
reasonable alternative to HTTP, one that is "adjacent" but not =
overly-specific? That would net us:

- WebRequest
- WebResponse
- WebResponseSender

I didn't like the look of it previously, and I don't think I like the =
look of it now, but ... (/me shrugs).


> However, that also may be confusing if people expect it to be a =
construct for making outgoing requests.=20

Yes, that's another tricky bit in the naming -- making a distinction =
between the objects as representative of client operations (send =
request, receive response) and server operations (receive request, send =
response). Thus the current `Server` prefix (however unsatisfactory it =
may be) to indicate their operational context.

Your `Incoming` and `Outgoing` prefixes, minus the HTTP, would net us:

- IncomingRequest
- OutgoingResponse
- OutgoingResponseSender

I will need to ponder on those.


> The user land implementation I=E2=80=99ve been using =E2=80=99solves=E2=80=
=99 this by using a `HTTP` namespace, and then provides `Request` and =
`Response` (for an outgoing - i.e. curl - HTTP Request, and the =
corresponding HTTP Response) objects and then `CurrentRequest` and =
`CurrentResponse` for what your RFC proposes (i.e. the active request =
made to php).=20

Yes, userland does operate that way. However, I think adding an HTTP =
namespace to PHP itself is something to be avoided, so emulating =
userland here is not an option.


> As with anything any of us has written, I=E2=80=99m not 100% sold on =
=E2=80=98Current{Request,Response}` even after writing it, but I think =
it=E2=80=99s at least a little more specific about what they do, when =
the namespace is taken into account.

`Current{...}` is not something we had previously considered; that would =
net us, in the global namespace:

- CurrentRequest
- CurrentResponse
- CurrentResponseSender

I will need to ponder on those as well.

Any further thoughts or opinions on this, Stephen? Or from anyone else?


--=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