Á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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
