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
