Re: Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

From: Date: Thu, 09 Dec 2010 16:17:31 +0000
Subject: Re: Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-50953@lists.php.net to get a copy of this message
Ángel González wrote:
Andrey Hristov wrote:
I am not against global variables, I'm against usage of $GLOBALS and "global".
So how do you support global variables by banning the two ways they can be accessed?
very easy, by using them by name. Global variables are those outside of a classes, methods and functions.
-1
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.
That's like trying to forbid TSRMLS_FETCH() in php source saying "just use TSRMLS_DC instead". Sure it is a nice goal but a) That's not always feasible [without rewriting an insane amount of code] b) It's not a restriction that should be imposed by the language. And in all possible places TSRMLS_FETCH() is being thrown out and replaced with TSRMLS_DC. You can check the commits to see this. If all functions were getting the ID of the thread context one could have have different than 1:1 mapping of request and OS threads - check the thread scheduler of MySQL 5.1 and 5.5.
Andrey

« previous php.internals (#50953) next »