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 :)"
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
