Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108493
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: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
Date: Tue, 11 Feb 2020 12:30:25 -0600
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <AD67C6CF-5195-49A5-8BD2-20B6D048ACBF@pmjones.io>
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
To: Mark Randall <marandall@php.net>
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: pmjones@pmjones.io (Paul M . Jones)

Hi Mark,

> On Feb 10, 2020, at 11:02, Mark Randall <marandall@php.net> wrote:
>=20
> I suspect this is a similar sentinment to the previous version, but I =
can personally see no major benefit to having this as a core extension.
>=20
> I think the reality is that discussing it "on its own merits" is to =
completely ignore the wider ecosystem that already performs these =
functions, with more capabilities, and with potentially hundreds of =
thousands of implementations already in place.
>=20
> Does it add capabilities which cannot exist in userland or cannot =
exist in a reasonably performant way? Doesn't seem so except for a =
readonly property.
>=20
> If not, leave it to userland.

I completely understand that sentiment; I recognize that it is shared by =
others on this list and elsewhere. But if you'll allow me, I'd like to =
present a counterargument in relation to previous PHP extensions.

When ext/pdo was added to core, there was already a "wider ecosystem =
that already performs these functions, with more capabilities, and with =
potentially hundreds of thousands of implementations already in place." =
Some of those implementations at the time included (I'm working from =
memory here) AdoDB, Metabase, MDB, PEAR_DB, and many more that I cannot =
recall.

PDO did not (to my knowledge) "add capabilities which cannot exist in =
userland or cannot exist in a reasonably performant way". (I'll grant =
that FETCH_INTO_OBJECT setting properties directly without using the =
constructor was not possible in userland, but that's an exception that =
tests the rule.) Indeed, PDO had a relatively reduced feature set in =
comparison to some of those userland libraries, especially AdoDB.

And yet, PDO has turned out to be of great benefit, because it brought =
together features into core that (figuratively speaking) everybody =
needed and was rewriting in userland over and over.

PDO is the strongest example here, but depending on how you count, there =
are 2-3 other extensions that also serve: ext/date, ext/phar, and =
(reaching back to antiquity) ext/session.

So, there is a long history of widely-needed userland functionality =
being brought into core. I would say this RFC is a pretty tame example =
of doing so; the proposal presented here is very similar to the way PHP =
itself already does things, just wrapped in object properties and =
methods, and is very similar to how things are being done across a wide =
swath of userland.

Now, it is possible that the objections you raise *should* have =
prevented PDO (et al.) from going into core. If that is the case, and =
(in hindsight) we think it was a mistake to allow them, then consistency =
alone makes your objections valid here as well.

However, if (in hindsight) it was *not* a mistake to allow those =
extensions, then the raised objections are not especially strong =
arguments against this RFC. That's not to say "because PDO was allowed =
into core, this RFC must therefore be allowed into core" but to say =
"those objections alone were not a barrier to PDO, so they alone should =
not be a barrier to this RFC".

I hope that's an understandable counterargument, even if you don't agree =
with it.


--=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