Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108513
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <CANUQDCiP31aEqULqeGpN66ESHarKxWuXgQt_CqWeCLZc+1L-fA@mail.gmail.com>
Date: Wed, 12 Feb 2020 13:39:27 -0500
Cc: "Paul M. Jones" <pmjones@pmjones.io>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <F4768B40-3455-411F-B62D-AA1AFAB7BDF3@newclarity.net>
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
 <CANUQDCiP31aEqULqeGpN66ESHarKxWuXgQt_CqWeCLZc+1L-fA@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: mike@newclarity.net (Mike Schinkel)

> On Feb 12, 2020, at 1:20 PM, Niklas Keller <me@kelunik.com> wrote:
> I think the request / response API is entirely fine being solved in
> userland instead of in php-src.

I want to disagree in support of this RFC.=20

While is *has* been solved in userland, but it has been solved 25+ times =
in 25+ different incompatible ways.  This RFC would allow for a *single* =
solution that is compatible across all frameworks, and frameworks could =
create a shim to support their existing implementations.=20

And given that it would be in core vs. userland, this would *not* apply: =
https://xkcd.com/927/

The one concern should be if there is anything about this RFC that would =
make writing such a shim impossible for any framework vendor?

> I think we shouldn't take over the naming of the super globals, e.g.
> $_GET really contains the query parameters and has nothing to do with
> GET or POST, so $request->getQueryParameter(...) would be a better
> name.

Please no. That is all too Java-esque verbosity. =20

Very commonly used functionality can afford to be concise like =
$request->get() because it would be well-known and not have to compete =
with lots of other functionality for mindshare.  Thus no need for this =
to be so precise and have such long names when everyone writing PHP =
would soon lean what it means.

> I don't see any reason to keep specials such as
> $_SERVER['HTTP_X_REQUESTED_WITH'] vs. $request->requestedWith, which
> is just another HTTP header.

Reason: $request->requestedWith can be type-safe, something you asked =
for in another context. =20

$_SERVER['HTTP_X_REQUESTED_WITH']  cannot be type safe without special =
cases in the language.

> The Request object should be mutable, e.g. you might want to change
> the client IP to be based on a x-forwarded-header instead of the TCP
> source address.

I totally agree it needs to be mutable, but only prior to first use.

After the first use having it be locked would gain us the benefits of =
robustness that immutability can provide.

-Mike=