Ángel González wrote:
Andrey Hristov wrote:
Ãngel González wrote:
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.
If they can only be used outside functions they would be more restricted
that eg. class variables.
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
As I said, that's a fine goal. There are more than 400 calls to
TSRMLS_FETCH() in the release tarball. Not all of them can be changed
with a TSRMLS_DC. Furthermore, the php project would be unhappy and
broken if one of the supported OS decided to remove all kinds of thread
local storage support (even thread ids!), on the basis of "being a bad
design".
interesting comparison of global variables with local data (thread local
storage)
Andrey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
