Superglobals are compiled into global fetches. However, we didn't want to
and don't want to slow down the average fetch by checking if it's a
superglobal first (i.e. variable variable). This also includes $this which
is evaluted at compile-time.
I think this is quite fair.
Andi
At 11:12 PM 2/3/
Sara Golemon wrote:
You won't hear a lot of argument from me. I just care less that it is the
way it is.
-Sara
:p. Ok, probably there will be some redesign when PHP 6 is on it's way,
perhaps not. :) Anyway, thanks for your time. ;)
Michael
--
PHP Internals - PHP Runtime Development Mailing Li
> ok, i see. But why does it work with variables that are set as global,
> e.g. the $HTTP_*_VARS:
>
> function test() {
> global $HTTP_GET_VARS;
> $a = 'HTTP_GET_VARS';
> var_dump($$a);
> }
> test();
> ?>
>
global $foo;
is the equivalent of:
$foo = &$GLOBALS['foo'];
So when you acces
ok, i see. But why does it work with variables that are set as global,
e.g. the $HTTP_*_VARS:
this works inside a function. is it because of the global keyword? If
so, why can't there be a "magic" "global $_GET, $_POST, $_SESSION ..."
set in every function, for every superglobal, instead of th
> i must admit, that i don't know very much about the zend engine and the
> php core in general, but if "opline->op2.u.EA.type" "knows" if the
> variable is a local one, a global one or a static one, why hasn't it the
> value of ZEND_FETCH_GLOBAL for superglobals in the first place?
>
opline->op
Sara Golemon wrote:
> Index: Zend/zend_execute.c
> ===
> RCS file: /repository/ZendEngine2/zend_execute.c,v
> retrieving revision 1.692
> diff -u -r1.692 zend_execute.c
> --- Zend/zend_execute.c 22 Jan 2005 02:29:18 - 1.692
>
>> how much does this patch slow execution down? it's one more hash lookup.
>> affect speed of $var or $$var? or both?
>>
> AFAICS, it should make every local-variable (non-global) lookup slower.
> Since it needs to do a lookup in the globals table first.
>
Slows the global ones too, though that c
AFAICS, it should make every local-variable (non-global) lookup slower.
Since it needs to do a lookup in the globals table first.
Xuefer Tinys wrote:
$_GET is solved at compile time, which is good, but this make other
variables bad at execution time?
how much does this patch slow execution down?
$_GET is solved at compile time, which is good, but this make other
variables bad at execution time?
how much does this patch slow execution down? it's one more hash lookup.
affect speed of $var or $$var? or both?
On Mon, 31 Jan 2005 14:24:41 -0800, Sara Golemon <[EMAIL PROTECTED]> wrote:
> > So
> So in order for ZE to resolve the autoglobals correctly during runtime it
> has to ask two questions for every *part* of every variable resolution:
"Are
> we checking against the active symbol table? Is the index we're looking
for
> in the autoglobal registry?" If so, replace active_symbol_tabl
> Atm it isn't possible to use a construct like $var = ${'_GET'}; inside a
> function or method. Will this behaviour change in future versions of
> PHP? I think it is somehow odd and inconsistent to not be able to use
> the superglobals that way, while it is possible outside of functions and
> meth
11 matches
Mail list logo
