Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108510
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: <5500e8e70ed1cdc162e5848b8959c63d8adc4853.camel@schlueters.de>
Date: Wed, 12 Feb 2020 10:54:11 -0600
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <6EE2BBA9-882A-4879-A6E7-E3262DD88B75@pmjones.io>
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
 <5500e8e70ed1cdc162e5848b8959c63d8adc4853.camel@schlueters.de>
To: =?utf-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: pmjones@pmjones.io ("Paul M. Jones")

Hi Johannes,


> What indication is there that this will be more successfull than the
> filter API?

Fair question. While I can't say how successful (or not) ext/filter has =
been, I *can* say that the proposal does not present extraordinary or =
dramatically different ways of working than PHP does currently.

The extent of the RFC is only to provide behaviors similar to what PHP =
already does, in object-oriented dress. That is, whereas ext/filter =
might have been been described as "a new and different way of working", =
the concepts and functions in this RFC (even down to the method and =
property names!) should be immediately familiar even to junior PHP =
developers.


> Historically PHP isn't really successful in providing higher level =
APIs
> to things and I think leaving this to userland is very viable, since
> composer and performance improvements in later PHP 5 and PHP 7.

I addressed the "userland" argument in my response to Mark Randall; =
please forgive me for not repeating it here.


> Also use of $_* is fast to grep for and gives me directly in the grep
> an idea about the mess-factor of a code base, tracing all calls to a
> member of an instance of a class is harder. (and yes, references etc.
> to super globals aren't trivial to trace, but also rare)

I feel your pain! I do a lot of legacy work too. The `$_` signature =
makes grepping easy, so that I can find places where there is =
spooky-action-at-a-distace from globally mutable state.

However, ServerRequest is intended to reduce or remove that globally =
mutable state. The $request->get property is readonly, and neither =
global nor superglobal. So, while it is tougher to grep for `->get` and =
know that you have found a ServerRequest property, the *need* to do so =
should be much less even in legacy codebases.


> Let PHP provide the access to the data and promote the API library of =
the year.

"API library of the year" -- heh.

To be fair, though, the API presented by ServerRequest and =
ServerResponse is highly similar to that presented by PHP itself; far =
from being "API of the year" it honors existing PHP functionality quite =
closely.


--=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