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-devm=104534556711383w=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-devw=2r=48s=New+PHP+extensionq=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: [EMAIL PROTECTED]
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
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 scopev =
(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: [EMAIL PROTECTED]
São Carlos - SP/Brazil Date: Thu, 8 Feb 2007 12:07:23 -0600 From: [EMAIL
PROTECTED] To: [EMAIL PROTECTED] 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-devm=104534556711383w=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-devw=2r=48s=New+PHP+extensionq=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
