Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100117
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.182 as permitted sender)
To: Kalle Sommer Nielsen <kalle@php.net>
Cc: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
References: <CAESVnVpF53Nn=K-CbVh8NSEqzebpdzZ7WgGsq91TWfo47GbEJw@mail.gmail.com>
 <CAJW__o3DUmmLmPPTSfeTEMFay19XhhoE3i8Z7gCXm4dwCx23Pg@mail.gmail.com>
 <12777d61-3277-413b-c60b-12c8c75bd76f@gmail.com>
 <CAJW__o2utYb5ZdKRrnSnmJ-_7G_7t+yHebME45BPWe6OowLiSQ@mail.gmail.com>
Message-ID: <a4293074-bf3e-155c-74a8-c33a21d08edd@gmail.com>
Date: Sat, 29 Jul 2017 17:18:56 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
 Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAJW__o2utYb5ZdKRrnSnmJ-_7G_7t+yHebME45BPWe6OowLiSQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Changes to SuperGlobals for PHP 8
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> Sure it seems useful, but I see it more as a hack if you are just
> writing to superglobals anyway, if you need to change something you
> should do that with your own logic instead.

That's what I said - you can always add a layer of indirection. But why?
What is so sacred in those variables that writing into them is taboo and
writing into intermediate layer is OK?

> If its something simple such as your code assumes $_GET['id'] always
> is available, then either write it to a temp variable.

Again, could do it, but why? What is so special in '_GET' that is not in
temp variable? Why make me do extra work?

> I know many applications nowadays are not written with an excess
> amount of globals everywhere, but writing to a global without
> explicitly declaring you want to, can cause some hard to debug cases
> if one function modifies a global and another assumes an unmodified
> value. I'd like to see that gone.

Request context is a global state. It is a legit global state -
everything within the request is executed in the context of the request.
If you put this global state into some kind of intermediate layer
instead of _GET, you would have absolutely the same global state issues.
You can write your app so that it extracts data from global state into
local state and does not depend on it, but this has nothing to do with
_GET itself - you could do it very well without changing anything with
_GET. Changing _GET does not solve the issues if you use global state,
and the issues do not exist if you don't.
-- 
Stas Malyshev
smalyshev@gmail.com