Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50953
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: <4D01011B.4090608@hristov.com>
Date: Thu, 09 Dec 2010 17:17:31 +0100
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: =?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?= <keisial@gmail.com>
CC: PHP Developers Mailing List <internals@lists.php.net>
References: <4D00ABFE.5070403@hristov.com> <AANLkTinDpmr2++Ys50tcbEPczrbz7eZKzXvvT+LG1CcD@mail.gmail.com> <4D00C86D.70208@hristov.com> <4D00FFDD.7040107@gmail.com>
In-Reply-To: <4D00FFDD.7040107@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)

Á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