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