Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108852
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: <CA+kxMuSzrxsXBra7TkFSz9-qbfVVikjW-FBr8juEsSOFNDx+pQ@mail.gmail.com>
Date: Wed, 4 Mar 2020 14:01:50 -0600
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <3F9CFD7B-22AB-4284-8E23-94513ABB5C3F@pmjones.io>
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
 <1657AB79-5CAF-4BCA-96B5-1343EC703CCD@pmjones.io>
 <CA+kxMuSzrxsXBra7TkFSz9-qbfVVikjW-FBr8juEsSOFNDx+pQ@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: pmjones@pmjones.io ("Paul M. Jones")

Hi Dan,

Thanks for taking the time to bring up your concerns. While I don't =
expect to change your mind (nice though that would be!) perhaps other =
readers here will find my counter-positions useful.


> On Mar 3, 2020, at 16:58, Dan Ackroyd <Danack@basereality.com> wrote:
>=20
> Paul M. Jones <pmjones@pmjones.io> wrote:
>=20
>> Are there any members here who currently expect to vote "no",
>=20
> The only reason for doing this as C code appears to be make it have
> read-only properties.

Not the *only* reason, though it's true that it would be =
difficult-to-impossible to do outside of C. As Rowan mentioned earlier, =
and as I opined in an unpublished version of the RFC, one other reason =
would be to provide a language-level OO-ish representation of PHP =
functions, similar to what ext/mysqli and ext/date do.


> This is a hack

I dispute the word "hack" -- a readonly feature is requested here from =
time to time -- though I do understand that it is an uncommon approach.


> that would confuse a lot of developers


I think you're right that it might confuse some developers, but I also =
opine that just as many or more would "get it" either right away or very =
quickly.


> and instantly be added to most lists of "how PHP is bad".


Adding one point to the many thousands that already exist on such =
ill-considered lists, so not much of a change there. ;-)


> Tying this into core means that:
>=20
> - BC breaking changes could only happen on major versions.
>=20
> - Discussion of those changes would take up a lot of time, or more
> likely never happen. See all of our core extensions that are
> desperately in need of a maintainer to work on them.
>=20
> - It might be impossible (or at least annoyingly difficult) to write
> code that was compatible with two versions of PHP, if they used this
>=20
> ...
>=20
> For stuff to be added to core, to overcome the burden of supporting in
> the future, there needs to be a strong reason to add it. Not just
> something that could be done.

All of your points are completely true. In fact, they are true for every =
RFC presented on this list; past, present, and future. So while you're =
correct, I have a hard time seeing it as a criticism specific to this =
proposal. (I'd be happy to see refinement of your points toward more =
specificity, if feel so inclined.)

Having said that, I'll present a past example that may tie it more =
specifically to this RFC. The Same Site Cookie proposal =
<https://wiki.php.net/rfc/same-site-cookie> hits around the points you =
mention: a change to long-standing behavior that might have entailed a =
BC break, discussion of that change, and code compatibility. All of =
those were managed quite successfully and in a reasonable timeframe. And =
although you voted against that proposal, it did pass, and has turned =
out to be pretty good; I imagine the same kind of change-success, if it =
is ever needed after adoption, is just as likely for this RFC as well.


> As you were involved and so know, a huge amount of energy was spent
> designing PSR-7, and still it was definitely not a perfect design. The
> chances of the design of this API being even as close as PSR-7 was,
> seems minimal.

I know you're not especially a fan of PSR-7 =
<http://basereality.com/blog/17/PSR7_and_airing_of_grievances> so =
arguing in its defense, against interest, is laudable. Good form!

But your phrasing about this RFC "being even as close as PSR-7 was" =
raises the question: "as close" to what?

The PSR-7 interfaces, and their many differing implementations, attempt =
to model HTTP messages as immutable objects. Indeed, the PSR-7 design =
process ended up discounting and discarding all pre-existing =
ways-of-working in PHP land, to the point of ignoring all previous =
implementations in the FIG member projects and elsewhere. Instead, PSR-7 =
declared "year zero" and presented an entirely new way of working that =
was completely different from and unrelated to anything else in PHP-land =
at that time. (For a brief history of the PSR-7 design evolution, see =
the first few slides of my talk on PSR-7 and ADR at =
<http://paul-m-jones.com/talks/psr7adr.pdf>.) Among other things, that =
meant there was no applicable real-world experience as to how well PSR-7 =
would work in the mid-to-long term.

That historical context may make it easier to see why "a huge amount of =
energy was spent designing PSR-7", while resulting in something that was =
"definitely not a perfect design", in order to get close to a model of =
HTTP messages.

This RFC, in contrast, does not attempt to model HTTP messages. It does =
not attempt to discard previous ways of working. Instead, it proposes a =
more object-oriented representation of functionality that already exists =
in PHP, honoring that previously-existing approach. There is quite a bit =
of real-world experience as to how well it will work, since it takes =
into account many commonalities between existing userland projects. =
Thus, what the RFC purports to get close to is that existing =
way-of-working, and I think it succeeds about as well as can be possible =
for its goals.


> In case anyone is interested, there is a book called 'Systemantics'
> that's actually quite applicable to open source projects....despite
> being written before personal computers were really a thing:
> https://en.wikipedia.org/wiki/Systemantics#First_principles
> =
https://www.amazon.co.uk/Systems-Bible-Beginners-Guide-Large/dp/0961825170=
/ref

I will add this to my reading backlog; thanks for the recommendation!


--=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