Re: Re: Bug #16687 Updated: Constants not being interpreted in "variable variables"

It applies, to a degree. If you directly reference $GLOBALS anywhere in your function, you can also reference it indirectly. If you don't, however, indirect reference won't work. E.g., function foo() {

        $foo = "GLOBALS";
        print $$foo["bar"];             // won't work

} function foo() {

        $GLOBALS;
        $foo = "GLOBALS";
        print $$foo["bar"];             // will work

} That's a side effect of implementation, though, so I think it's best to say that indirect reference to $GLOBALS is not supported. Zeev At 19:48 20/04/2002, Markus Fischer wrote:

    Andi,

    does this also apply to the $GLOBALS variable?

    If so, I think we can then add an apropriate Note: to the
    http://www.php.net/manual/en/language.variables.predefined.php
    page.

    - Markus

On Sat, Apr 20, 2002 at 04:23:03PM +0300, Andi Gutmans wrote : The way _GET and friends are implemented is the most efficient way of doing it as it is taken care at compile-time. For the same reason in Engine 2 you can't indirectly reference $this (which shouldn't bother anyone). Over time people won't have to support versions below 4.1.0 anymore. In the meanwhile I suggest you keep on using $HTTP_*_VARS until you find that you can move to _GET. I don't want to screw up the implementation and performance of _GET for BC. If you need BC you should stick to the old ones that is why they have been left behind. Andi At 15:32 19/04/2002 -0500, Lux wrote:

On Fri, 2002-04-19 at 15:08, Zeev Suraski wrote:

At 21:18 19/04/2002, Lux wrote:

One other quick question: Can you make references to the superglobals, then call these as "variable variables"?

Yes. Can you explain when you need to use these global structures indirectly?

Sure! In an effort to be compatible with PHP 4.0.6 and under as well as 4.1.0+, I found myself using the following code more than once: if (PHP_VERSION < '4.1.0') { // use $HTTP_*_VARS } else { // use $_* vars } While I know I can still use the $HTTP_*_VARS in all new versions of PHP, the docs on php.net stated that these were deprecated, so I am preparing for versions that didn't have them by starting to move towards the new variables now. But I can't ditch the $HTTP_*_VARS way completely for a while still, because there are a lot of PHP users still running 4.0.6. So I thought of a method of only having to code this if statement once, which was: if (PHP_VERSION < '4.1.0') { define ('_GET', 'HTTP_GET_VARS'); define ('_POST', 'HTTP_POST_VARS'); // etc. } else { define ('_GET', '_GET'); define ('_POST', '_POST'); // etc. } Now I can refer to the appropriate values automatically by saying ${_GET} or ${_POST}, which is only two characters off from using the new syntax, so it's nice and simple. The only catch here is that in any block that I use these, I have to call global $HTTP_*_VARS first to whichever I use, otherwise it keeps my code nice and clean. Reasons aside though, we are talking about an inconsistency in the way PHP handles these new "superglobals", one that makes them look and feel and act (for the most part) just like ordinary variables, but makes them differ in small but potentially problematic ways. Using my method works in the global namespace, but once you enter another it fails. This sounds like a pretty clear bug to me, not something to be excused as "we meant for it to be that way". Nobody plans to add tiny inconsistencies; those only make peoples' lives more difficult. Lux

Zeev

-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc "Mind if I MFH ?" "What QA did you do on it?" "the usual?" "ah... none :)"