Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108860
MIME-Version: 1.0
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io> <1657AB79-5CAF-4BCA-96B5-1343EC703CCD@pmjones.io>
In-Reply-To: <1657AB79-5CAF-4BCA-96B5-1343EC703CCD@pmjones.io>
Date: Thu, 5 Mar 2020 09:00:56 +0000
Message-ID: <CAJvSBVOEbs4UZ6ScXmwP9-SvZWrEE6Efk+TNBHC-b+ShuozuAQ@mail.gmail.com>
To: "Paul M. Jones" <pmjones@pmjones.io>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000085a7ae05a017c842"
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: phpmailinglists@gmail.com (Peter Bowyer)

--00000000000085a7ae05a017c842
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 28 Feb 2020 at 15:25, Paul M. Jones <pmjones@pmjones.io> wrote:

> Are there any members here who currently expect to vote "no", who have no=
t
> yet chimed in? I'd like to hear your criticisms and objections, so I can =
at
> least attempt to resolve your concerns.
>

I expect to vote "no". My thoughts are:

1. The chosen API. We have an OO approach, but headers and query parameters
are accessed through an array-style mechanism. I'm not a fan of the way
everything maps onto ServerRequest, with certain $_SERVER vars promoted to
be part of it (but not all AFAICT).

2. The OO-ish approach. For a core feature which will be around for 20+
years I would like a pure(r) OO approach taken, and time to be taken to get
that right. What you have is pragmatic, but as I say in (1) not something
I'm a fan of. Rowan Tommins on 18 Feb 2020 at 20:21 expressed this well
(link: https://externals.io/message/108436#108661).

3. WRT the RFC:
a) there is no section on where this came from. With your involvement in
PSR-7 it looks to be an area you've given much thought to. Why did you
develop ext/request? What problem(s) did you see that this is the answer
to? I skimmed the thread but didn't pick out a clear answer to this.
b) Did you look at how other languages and/or frameworks deal with requests
and responses, and was there inspiration and lessons you took from their
successes (or failures)? [For me this is a key omission in most PHP RFCs]

Thinking about porting existing codebases across, ServerRequest holding
copies rather than references would make it hard to interop with existing
code using the superglobals. I've had this rewriting legacy apps that use
$_SESSION and the new framework uses an OO session handler; it's not fun
but with references can usually be made to work. In this case, what would
the migration path look like? Johannes Schl=C3=BCter commented on this on 2=
4 Feb
but I didn't understand his comment (link:
https://externals.io/message/108436#108737).

In summary, I like the idea of steering people away from superglobals,
appreciate the work you've put in, and am not persuaded by the approach.

Peter

--00000000000085a7ae05a017c842--