Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109001
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: <0B40E6E5-342F-4D81-9CAA-A0C0739A7718@pmjones.io>
Date: Fri, 13 Mar 2020 21:23:59 +0700
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <C3C15896-923D-4386-A991-329D0FCE7CC9@koalephant.com>
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>
To: "Paul M. Jones" <pmjones@pmjones.io>
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: php-lists@koalephant.com (Stephen Reay)



> On 13 Mar 2020, at 20:39, Paul M. Jones <pmjones@pmjones.io> wrote:
>=20
> Hi Stephen,
>=20
>> On Mar 13, 2020, at 02:41, Stephen Reay <php-lists@koalephant.com> =
wrote:
>>=20
>> I realise this is just bike shedding - the naming seems quite odd to =
me.
>>=20
>> This extension and the classes it provides are inherently about HTTP =
requests made to a php =E2=80=98server=E2=80=99, and the response it =
sends back - and yet it=E2=80=99s called Server{Request,Response,Buffer} =
etc=E2=80=A6. The =E2=80=9Cserver=E2=80=9D part is superfluous in the =
context of a php web application, because it=E2=80=99s all =E2=80=9Cserver=
=E2=80=9D side, and while uncommon it=E2=80=99s not impossible to write =
*other* types of network server using PHP.
>=20
> I share your feeling here, and I don't think it's bike shedding. The =
naming is still an open question on the RFC.
>=20
> I mentioned some other candidate names here ...
>=20
>  https://externals.io/message/108436#108702
>=20
> ... and re-reading your comment above, it looks like you saw that one.
>=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
> Let me know, and thanks for bringing it up!
>=20
>=20
> --=20
> Paul M. Jones
> pmjones@pmjones.io
> http://paul-m-jones.com
>=20
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
>=20
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20

Hi Paul,


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.


I think I did see that message, but I must admit I haven=E2=80=99t =
followed all the responses in the discussion.

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.

However, that also may be confusing if people expect it to be a =
construct for making outgoing requests.=20
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). 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.


Cheers

Stephen