On Fri, 2002-04-19 at 13:07, Derick Rethans wrote:
> On 19 Apr 2002 [EMAIL PROTECTED] wrote:
> 
> >  ID:               16687
> >  Updated by:       [EMAIL PROTECTED]
> >  Reported By:      [EMAIL PROTECTED]
> >  Status:           Bogus
> >  Bug Type:         Scripting Engine problem
> >  Operating System: Red Hat Linux 7.1
> >  PHP Version:      4.2.0
> >  New Comment:
> > 
> > But then why does it work under certain circumstances and not others? 
> > Regardless whether intended or not, this is inconsistent behaviour.
> 
> Yes it is indeed.

Shouldn't this be made consistent then?

> 
> > I also think that having these differences between regular variables
> > and the "superglobals" shouldn't be necessary.  If I can't use them in
> > the same contexts as regular variables, then I would personally prefer
> > the $HTTP_*_VARS instead, because you can.
> > 
> > I have found my approach to abstracting this difference ($HTTP_*_VARS
> > vs. $_*) between PHP versions to be really beneficial to my scripts.  I
> > can abstract them both down to one name, and use a single reference to
> > the appropriate one instead of sticking if statements every time I need
> > to know which one to use.
> 
> Then just stick to $HTTP_*_VARS and you dont need no fancy references. 
> This works with akk versions of PHP. But I strongly recommend to use the 
> $_* variant for new projects.

But aren't the $HTTP_*_VARS deprecated in favour of the new $_*
variables?  That's why I was trying to come up with a singular syntax
(ie ${_GET}) to reference whichever is appropriate, because I do like
the $_* vars much better, and I don't want to invest effort in one then
have to switch later.  Also, with regards to this behavioral
inconsistency, if I do stick to $HTTP_*_VARS, and come to rely on them
behaving like ordinary variables do, then it might break something later
on to switch.  Predictability here and now could prevent problems down
the road.

One other quick question:  Can you make references to the superglobals,
then call these as "variable variables"?  That still makes it more
troublesome because then I have to be careful to call global $a, $b, $c
on any ones I want to use, in addition to already having to call global
$HTTP_*_VARS in case they're using 4.0.6 or earlier.

Thanks for the feedback!

Lux

> 
> regards,
> 
> Derick
> 
> > Previous Comments:
> > ------------------------------------------------------------------------
> > 
> > [2002-04-19 10:33:59] [EMAIL PROTECTED]
> > 
> > You can't use superglobals indirectly, check this:
> > 
> > $t = "_GET";
> > var_dump ($$t);
> > 
> > doesn't work neither, and it wasn't supposed to work.
> > 
> > However, this does work (because $HTTP_GET_VARS is not a superglobal):
> > 
> > $t = "HTTP_GET_VARS";
> > var_dump ($$t);
> > 
> > 
> > Derick
> > 
> > ------------------------------------------------------------------------
> > 
> > [2002-04-18 19:09:09] [EMAIL PROTECTED]
> > 
> > reclassified
> > 
> > ------------------------------------------------------------------------
> > 
> > [2002-04-18 17:30:28] [EMAIL PROTECTED]
> > 
> > It seems to be happening only under certain contexts.  Here is a script
> > that works fine:
> > 
> > <?php
> > 
> > $test = 'asdf';
> > 
> > define ('_TEST', 'test');
> > 
> > echo 'constant: ';
> > print_r (${_TEST});
> > 
> > echo '<br />direct: ';
> > print_r ($test);
> > 
> > ?>
> > 
> > And here is code that does not:
> > 
> > <?php
> > 
> > if (PHP_VERSION < '4.1.0') {
> >     define ('_GET', 'HTTP_GET_VARS');
> > } else {
> >     define ('_GET', '_GET');
> > }
> > 
> > class CGI {
> >     var $param = array ();
> > 
> >     function CGI () {
> >             global $HTTP_GET_VARS, $HTTP_POST_VARS, $HTTP_POST_FILES;
> > 
> >             if (${_GET}) {
> >                     reset (${_GET});
> >                     while (list ($k, $v) = each (${_GET})) {
> >                             if (get_magic_quotes_gpc () == 1) {
> >                                     $this->{$k} = stripslashes ($v);
> >                             } else {
> >                                     $this->{$k} = $v;
> >                             }
> >                             array_push ($this->param, $k);
> >                     }
> >             } else {
> >                     echo '<br />_GET value: '; print_r (_GET);
> >                     echo '<br />$_GET value: '; print_r ($_GET);
> >                     echo '<br />${_GET} value: '; print_r (${_GET});
> >             }
> >     }
> > }
> > 
> > $cgi = new CGI;
> > 
> > echo '<br />$cgi value: '; print_r ($cgi);
> > 
> > ?>
> > 
> > ------------------------------------------------------------------------
> > 
> > [2002-04-18 16:43:17] [EMAIL PROTECTED]
> > 
> > Constants do not appear to be interpreted properly in the following
> > context:
> > 
> > ${CONSTANT}
> > 
> > I found this problem with the following code:
> > 
> > <?php
> > 
> > if (PHP_VERSION < '4.1.0') {
> >   define ('_GET', 'HTTP_GET_VARS');
> >   // etc.
> > } else {
> >   define ('_GET', '_GET');
> >   // etc.
> > }
> > 
> > print_r (${_GET});
> > 
> > ?>
> > 
> > This should print out the $_GET hash in 4.2.0RC4, but it prints
> > nothing.  A quick check of the _GET constant shows that it does contain
> > the proper value.
> > 
> > I compile php with:
> > 
> > './configure' '--with-pgsql=shared' '--with-gd'
> > '--with-mysql=/usr/local/mysql'
> > '--with-apxs2=/usr/local/apache2/bin/apxs' '--enable-shmop'
> > '--enable-xslt' '--with-xslt-sablot'
> > 
> > Thanks!
> > 
> > ------------------------------------------------------------------------
> > 
> > 
> > -- 
> > Edit this bug report at http://bugs.php.net/?id=16687&edit=1
> > 
> 
> 
> 



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

Reply via email to