Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108440
Message-ID: <5500e8e70ed1cdc162e5848b8959c63d8adc4853.camel@schlueters.de>
To: "Paul M. Jones" <pmjones@pmjones.io>, internals@lists.php.net
Date: Mon, 10 Feb 2020 21:44:29 +0100
In-Reply-To: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

Hi,

On Mon, 2020-02-10 at 10:18 -0600, Paul M. Jones wrote:
> After a couple of years of incubation, I am happy to offer a second
> version of this RFC:
> 
>   https://wiki.php.net/rfc/request_response

What indication is there that this will be more successfull than the
filter API? The filter API was our previous attempt to improve upon
input handling. With this new API we have three major ways
(superglobals, filter, new API) 

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.

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)

Let PHP provide the access to the data and promote the API library of
the year.

johannes