Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108737
Message-ID: <7eecdcc9e85b338f9869b4037647db63279c97e3.camel@schlueters.de>
To: "Paul M. Jones" <pmjones@pmjones.io>
Cc: internals@lists.php.net
Date: Mon, 24 Feb 2020 14:57:20 +0100
In-Reply-To: <6EE2BBA9-882A-4879-A6E7-E3262DD88B75@pmjones.io>
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
	 <5500e8e70ed1cdc162e5848b8959c63d8adc4853.camel@schlueters.de>
	 <6EE2BBA9-882A-4879-A6E7-E3262DD88B75@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?=)

On Wed, 2020-02-12 at 10:54 -0600, Paul M. Jones wrote:
> 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.

Is there a way to integrate filter, so we can reduce (over the long
term) the interfaces and get to a single one (getting rid of
register_globals took almost to the day 10 years from creating super
globals, via deprecation and changed default to removal, so I'm not
asking for the unity tomorrow but having a plan ...) 

(Or we could say filter failed completely and we don'T integrate it and
just remove it :-p no idea ...)

> > 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.

As a side note: I love the fact that the low layer is mutable. It
allows me to take legacy code and wrap it in a more modern framework
and fake the old environment as a migration strategy (one has to be
aware this produced debt and needs a plan to get rid of that, but can
be practical for a migration rather than rewrite, also useful for
testing bad code to allow cleanup)

> > 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.

So it's only "closely" to what users want? So users will still need to
wrap it? So purpose is not to make it simpler to use or anything but
only to disallow abuses like I mentioned above?

I understand why people hate the mutability there, but I think it is a
quality of PHP to not stand in the way when crazy things have to be
done. And maybe the cases where the mutability can be solved with a
FakeServerRequest implementing the same interface easily ... then the
question is whether we get users migrated over ... $_GET is in each and
every tutorial and code since 2001, when it was introduced in PHP 4.1
...

johannes