Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50941
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hristov.com from 85.92.87.36 cause and error)
Message-ID: <4D00C86D.70208@hristov.com>
Date: Thu, 09 Dec 2010 13:15:41 +0100
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Ferenc Kovacs <info@tyrael.hu>
CC: PHP Internals List <internals@lists.php.net>
References: <4D00ABFE.5070403@hristov.com> <AANLkTinDpmr2++Ys50tcbEPczrbz7eZKzXvvT+LG1CcD@mail.gmail.com>
In-Reply-To: <AANLkTinDpmr2++Ys50tcbEPczrbz7eZKzXvvT+LG1CcD@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST,
 $_GET, $_POST read-only
From: php@hristov.com (Andrey Hristov)

Ferenc Kovacs wrote:
> 
> 
> On Thu, Dec 9, 2010 at 11:14 AM, Andrey Hristov <php@hristov.com 
> <mailto:php@hristov.com>> wrote:
> 
>     Â Hi guys,
>     the topic says most of it. What do you think about deprecating the
>     global keyword and $GLOBALS with it? Together with this making
>     $_REQUEST, $_GET and $_POST read-only as they should be used only to
>     read-only anyway.
> 
>     The reason for global + GLOBALS is that these are abused and which
>     leads to spaghetti programs, when used by unexperienced users. Also
>     they have impact on side effects from functions that don't only rely
>     their parameters.
> 
>     Best,
>     Andrey
> 
> 
> Please next time write an rfc before starting a thread like this.

a RFC can crystalize from this thread.

> I'm pretty much against the idea.
> That would be the most dramatic change in the language in the history of 
> php.

pretty dramatic change was the change to the object model between 4 and 
5. Dropping the usage of references, dropping of exchange of $this. And 
also register_globals. register_globals was harder to fix, because you 
can't just grep and find what variables you need from the URLs. 
Situation is different with $GLOBALS and "global", as a single grep can 
show you whether an application needs change or not.

> The register_globals is/was a much bigger problem/bad practice and it 
> take 10 years to remove it(we are almost there...).
> And to fix the applications, one would either completely restructure all 
> of the functions/methods to pass all of the required data from the 
> global scope, or they would do the easy way: export all of the global 
> variables into a singleton registry.

I am not against global variables, I'm against usage of $GLOBALS and 
"global".

>  From a Framework point of view, they should save all of the 
> (super)global variables from the global scope, because the frameworks 
> doesn't use/run code in the global scope except the bootstrap, so they 
> couldn't access that either, but they won't know what the developer who 
> uses the framework want's to access from the global scope.
> And what about global constants? They are also screwing up the 
> Dependency Injection, and the static functions/properties, and the 
> Â singletons also. Â Should we ban those?

no, you got me wrong. I will repeat - global variables won't cease to 
exist, but $GLOBALS and "global" as means to access them should be 
removed. If a function needs data it should get it passed to it.

> Tyrael

Andrey