RE: [PHP-DEV] Suggestion: global variables being accessed in local scope

Brian,I am sorry about the message indentation... Seems PHP-Internals list does not like M$ Live(r) Mail! roflI wrote it carefully indented... =\I read your extension messages, but you idea was different from mine. What you suggested in that post is exactly what runkit does today.My idea is a little bit different. If possible, the idea is something like this (sorry, but my C skill are not so good and I'll write in Java):I extracted the source from a Krakatoa compiler I wrote (Krakatoa => C)...Currently, PHP tries to access a local variable usage/assignment with this (Compiler class scope):// Retrieve variable from local scopeVariable v = (Variable ) this.symbolTable.getInLocal( this.lexer.getStringValue() );if ( v == null ) { // Variable does not exist in local scope, throw a fatal error. this.error.show("FATAL ERROR: Undefined Variable " + this.lexer.getStringValue(), CompilerError.FATAL_ERROR);}The best approach that I suggested eliminates the need of global keyword and also the $GLOBALS autoglobal array.The source code I have to do what I suggest is this:// Retrieve variable from local scope Variable v = (Variable ) this.symbolTable.getInLocal( this.lexer.getStringValue() ); if ( v == null ) { // Try to retrieve the variable from global scope v = (Variable ) this.symbolTable.getInGlobal( this.lexer.getStringValue() ); if ( v == null ) { // Variable does not exist in local nor in global scope, throw a fatal error. this.error.show("FATAL ERROR: Undefined Variable " + this.lexer.getStringValue(), CompilerError.FATAL_ERROR); } }As you can see, the only change needed is in a throw-able error (Undefined variable), which does a second look-up in the symbolTable.Doing this, you do not need to use $GLOBALS nevermore! And also, global can be extinct too, since the compiler recognizes the variable in global scope alone.I know the PHP source is not well commented and structured, but I think this is not an impossible change to be done, and will bring a lot of benefits to all PHP developers.I wish God come here and make my message indented until it reaches the PHP-Internals list.... =DBest 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> Date: Thu, 8 Feb 2007 12:07:23 -0600> From: brianm@dealnews.com> To: guilhermeblanco@hotmail.com> CC: internals@lists.php.net> Subject: Re: [PHP-DEV] Suggestion: global variables being accessed in local scope> > 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 =)> > -- > PHP Internals - PHP Runtime Development Mailing List> To unsubscribe, visit: http://www.php.net/unsub.php> _________________________________________________________________ Ligue para os seus amigos grátis. Faça chamadas de PC-para-PC pelo messenger-- GRÁTIS http://get.live.com/messenger/overview