Suggestion: global variables being accessed in local scope

php.internals

Guilherme Blanco

19 years ago
Hello PHP maintainers,During this week, I spoke with Sara Golemon about the possibility to change one current behavior of PHP.My first suggestion, as you can see in my blog post: http://blog.bisna.com/archives/32#comments was a new function called register_superglobal.While talking with her, I found that it'll be easier to be implemented another thing.Currently, when we deal with objects and functions in a PHP application, to access most common variables, we have to do one of these things:function m() { global $DB; // ...}Another one:function m() { $DB = Database::getInstance(); // ...}Or:function m() { $DB = Registry::get("DB"); // ...}And finally... via Factory:function m() { $DB = Env::getDatabaseConnection(); // ...}We can also specify via runkit a superglobal variable (DB), and use it.While all those solutions have some costs, maybe there is a possibility to change the structure and simplify all those lines of code.As I already said, my first idea was a function, register_superglobal, which you register it and access it in a local scope without using none of the examples I listed.Sara told me about superglobals and etc, but I suggested her about the possibility to change the idea a little. Here is the comment I describe 2 possible ideas:"The perfect behavior should be (inside a function), if a variable does not exist, try to access a global (without doing via $GLOBALS or global). If it doesn’t exist in the second try, then throw a fatal error. With this, you do not need to think in superglobal variable or anything else. Maybe this suggestion is currently too much difficult to achieve. The workaround can be done using normal variables. But, as I mentioned before, when the statement uses a variable, it checks for the local variables declarations hash table; the idea is different here… if the variable does not exist in local, look in the hash table I mentioned (which stores the subscribed variables to behavior like superglobal) and, if found, grab the variable from the global variable declarations hash table. As you can see, there will be only one performance impact (in normal variable), doing a hash table checking. You do not need to change autoglobal or static variables. In an average system, the needed time to do this checking will be an advantage than the currently best approach (Registry). You lose in one side, but receive more in the other."She agreed with my idea ("That’s all doable, and with autoglobals being CVs now, it’s even doable without too much performance impact on the global fetches themselves…"), BUT she said I will have to convince engine team to accept this idea too. Also, she said that will be a too much added complexity for too little. I disagree with her, since currently there are much more processment retrieving one object from a Registry or using a global accessor than another compiler hash checking. The performance impact is almost irrelevant (cannot be measured) and the final solution is cleaner than all the others. If you look at real world large applications, you can experience these workarounds. And, as I checked with my contact list (around 600), it'll be a great improvement of PHP.Now I am leaving this suggestion to internals list, and I hope you look affectionately at it.Best regards,Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9166-6902 URL: http://blog.bisna.com MSN: guilhermeblanco@hotmail.com São Carlos - SP/Brazil _________________________________________________________________ O Windows Live Spaces está aqui! Descubra como é fácil criar seu espaço na Web e sua rede amigos. http://spaces.live.com/signup.aspx

Brian Moon

19 years ago
Well, this was a little hard to read, but, let me see if I understand one thing. You would have PHP look in the local scope and then also in the global scope? If so, I would never support that idea. I remember an email from Rasmus about why PHP's scoping is the way it is. Something to do with chasing down a scope issue in a C app for days. I wrote an extension to do this about 4 years ago. I submitted it to the, then pear-dev list. http://marc.theaimsgroup.com/?l=pear-dev&m=104534556711383&w=2 It was not received well, so I did not pursue it. To see all the replies look at http://marc.theaimsgroup.com/?l=pear-dev&w=2&r=48&s=New+PHP+extension&q=b and read the ones titled "New PHP Extension". MARC did not thread the discussion well. My extension did not have a function, but required php.ini settings to declare the variable names. It also required they start with and under score if I remember correctly. Now the bad news. The code was lost in a hard drive crash. I am not sure it would work now though. I am sure a lot has changed in 4 years. Guilherme Blanco wrote:
> Hello PHP maintainers,During this week, I spoke with Sara Golemon about the possibility to change one current behavior of PHP.My first suggestion, as you can see in my blog post: http://blog.bisna.com/archives/32#comments was a new function called register_superglobal.While talking with her, I found that it'll be easier to be implemented another thing.Currently, when we deal with objects and functions in a PHP application, to access most common variables, we have to do one of these things:function m() { global $DB; // ...}Another one:function m() { $DB = Database::getInstance(); // ...}Or:function m() { $DB = Registry::get("DB"); // ...}And finally... via Factory:function m() { $DB = Env::getDatabaseConnection(); // ...}We can also specify via runkit a superglobal variable (DB), and use it.While all those solutions have some costs, maybe there is a possibility to change the structure and simplify all those lines of code.As I already said, my first idea was a
function, register_superglobal, which you register it and access it in a local scope without using none of the examples I listed.Sara told me about superglobals and etc, but I suggested her about the possibility to change the idea a little. Here is the comment I describe 2 possible ideas:"The perfect behavior should be (inside a function), if a variable
> does not exist, try to access a global (without doing via $GLOBALS or > global). If it doesn’t exist in the second try, then throw a fatal > error. With this, you do not need to think in superglobal variable or > anything else. Maybe this suggestion is currently too much difficult to achieve. > The workaround can be done using normal variables. But, as I > mentioned before, when the statement uses a variable, it checks for the > local variables declarations hash table; the idea is different here… if > the variable does not exist in local, look in the hash table I > mentioned (which stores the subscribed variables to behavior like > superglobal) and, if found, grab the variable from the global variable > declarations hash table. > As you can see, there will be only one performance impact (in normal > variable), doing a hash table checking. You do not need to change > autoglobal or static variables. In an average system, the needed time > to do this checking will be an advantage than the currently best > approach (Registry). You lose in one side, but receive more in the > other."She agreed with my idea ("That’s all doable, and with autoglobals being CVs now, it’s even doable > without too much performance impact on the global fetches themselves…"), BUT she said I will have to convince engine team to accept this idea too. Also, she said that will be a too much added complexity for too little. I disagree with her, since currently there are much more processment retrieving one object from a Registry or using a global accessor than another compiler hash checking. The performance impact is almost irrelevant (cannot be measured) and the final solution is cleaner than all the others. If you look at real world large applications, you can experience these workarounds. And, as I checked with my contact list (around 600), it'll be a great improvement of PHP.Now I am leaving this suggestion to internals list, and I hope you look affectionately at it.Best regards,Guilherme Blanco - Web Developer > CBC - Certified Bindows Consultant > Cell Phone: +55 (16) 9166-6902 > URL: http://blog.bisna.com > MSN: guilhermeblanco@hotmail.com > São Carlos - SP/Brazil > _________________________________________________________________ > O Windows Live Spaces está aqui! Descubra como é fácil criar seu espaço na Web e sua rede amigos. > http://spaces.live.com/signup.aspx
-- Brian Moon ------------- http://dealnews.com/ It's good to be cheap =)

Unknown W. Brackets

19 years ago
Question. Given this code: function foo() { $bar = 1; } $bar = 5; foo(); echo $bar; What should happen? You seem to be saying that "1" should be output. Clearly this would not be backwards compatible, and would most likely break code. -[Unknown] -------- Original Message --------
> Hello PHP maintainers,During this week, I spoke with Sara Golemon about the possibility to change one current behavior of PHP.My first suggestion, as you can see in my blog post: http://blog.bisna.com/archives/32#comments was a new function called register_superglobal.While talking with her, I found that it'll be easier to be implemented another thing.Currently, when we deal with objects and functions in a PHP application, to access most common variables, we have to do one of these things:function m() { global $DB; // ...}Another one:function m() { $DB = Database::getInstance(); // ...}Or:function m() { $DB = Registry::get("DB"); // ...}And finally... via Factory:function m() { $DB = Env::getDatabaseConnection(); // ...}We can also specify via runkit a superglobal variable (DB), and use it.While all those solutions have some costs, maybe there is a possibility to change the structure and simplify all those lines of code.As I already said, my first idea was a
function, register_superglobal, which you register it and access it in a local scope without using none of the examples I listed.Sara told me about superglobals and etc, but I suggested her about the possibility to change the idea a little. Here is the comment I describe 2 possible ideas:"The perfect behavior should be (inside a function), if a variable