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: [EMAIL PROTECTED]
São Carlos - SP/Brazil> Date: Thu, 8 Feb 2007 12:07:23 -0600> From: [EMAIL
PROTECTED]> To: [EMAIL PROTECTED]> CC: [email protected]> 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: [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>
_________________________________________________________________
Ligue para os seus amigos grátis. Faça chamadas de PC-para-PC pelo messenger--
GRÁTIS
http://get.live.com/messenger/overview
