Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107280
MIME-Version: 1.0
References: <CAP=w73Xe+x92W7K8dVXjH+e+shk8+Ui8J5v7T94X=+qdTJoQsg@mail.gmail.com>
 <CAF+90c82NSW+Mr483ycFnjNRDcEW0cSnwoM1r4OzGdMtPCuNYA@mail.gmail.com>
 <CAP=w73Uevg9visVP1k+w-oqySMoH8420Y2jHjsh+h1dyGmLKZQ@mail.gmail.com> <CAF+90c-S4k=p4c_xJc-+1pFXSRUF4LkbruN9QRoa2+6VkrVSqQ@mail.gmail.com>
In-Reply-To: <CAF+90c-S4k=p4c_xJc-+1pFXSRUF4LkbruN9QRoa2+6VkrVSqQ@mail.gmail.com>
Date: Sat, 21 Sep 2019 19:09:21 +0700
Message-ID: <CAP=w73W8HUdc39Afaxggz4D1Vbb=f=OaQ57To9P+=4oakvzcYA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000046938105930f0fbd"
Subject: Re: [PHP-DEV] Question about `global` variable declaration
From: webdevxp.com@gmail.com (Kosit Supanyo)

--00000000000046938105930f0fbd
Content-Type: text/plain; charset="UTF-8"

I understand your point but inconsistency in my sense is syntactical By
comparing to other declaration syntax like `var`, `static`, 'public` an
others. They allow only T_VARIABLE but `global` is different. And there's
another way to archive the same goal through `$GLOBALS`, that's why I see
it as inconsistency.

P.S. I wrote this not because I want to convince you to make any change but
just to explain my point.

Cheers

On Sat, Sep 21, 2019 at 6:24 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Sat, Sep 21, 2019 at 12:58 PM Kosit Supanyo <webdevxp.com@gmail.com>
> wrote:
>
>> Hi Dan and Internals
>>
>> Sorry  Dan, I forgot to include @Internals in previous reply so let me
>> resend this again.
>>
>> Thank you for your reply. I see, but in that case it can be done with
>> `$GLOBALS['abc']` right? So I don't see any benefits of allowing those
>> forms, they're just another inconsistency that should not exist from the
>> beginning. Yes, it does no harms but if nobody is really using it at all,
>> is it good to remove this inconsistency? Or to make it really useful, why
>> not just allow assignment like:
>>
>> global ${'abc'} = $someValue;
>>
>> Just my 2 cents.
>>
>> Regards
>>
>
> global $x; is a shorthand for $x =& $GLOBALS['x'];
> global ${$x}; is a shorthand for ${$x} =& $GLOBALS[$x];
>
> I don't think this syntax is inconsistent so long as PHP supports the
> syntax ${$x} for variables in general.
>
> The idea of a "global ${'abc'} = $someValue;" syntax doesn't seem to have
> a relation to the ${} form in particular. A simple "global $var =
> $someValue" is currently not supported either. That's because "global $var"
> simply imports a global variable into the local scope. You would instead
> write this as "global $var; $var = $someValue;".
>
> Nikita
>
>
>> On Sat, Sep 21, 2019 at 5:52 PM Nikita Popov <nikita.ppv@gmail.com>
>> wrote:
>>
>>> On Sat, Sep 21, 2019 at 11:56 AM Kosit Supanyo <webdevxp.com@gmail.com>
>>> wrote:
>>>
>>>> Hi Internals
>>>>
>>>> I'm working on my new proposals and I've found weirdness of global
>>>> variable
>>>> declaration in zend_language_parser.y.
>>>>
>>>> global_var:
>>>>     simple_variable
>>>>         { $$ = zend_ast_create(ZEND_AST_GLOBAL,
>>>> zend_ast_create(ZEND_AST_VAR, $1)); }
>>>> ;
>>>>
>>>> Above grammer allows something like this...
>>>>
>>>> global $$x;
>>>> global $$$y;
>>>> global $$$$z;
>>>> global ${'abc'};
>>>> global $$$$$$$$$${random_int(0, PHP_INT_MAX)};
>>>>
>>>> What's the propose of allowing this? And is there anyone out there
>>>> knowing
>>>> and using it? If not, should this be changed to allow only T_VARIABLE to
>>>> make it consistent with `static` variable declaration?
>>>>
>>>> Regards
>>>>
>>>
>>> Some grep results:
>>>
>>> sources/adodb/adodb-php/session/adodb-session.php
>>> 676: global $$var;
>>> 697: global $$var;
>>>
>>> sources/adodb/adodb-php/session/adodb-session2.php
>>> 719: global $$var;
>>> 740: global $$var;
>>>
>>> sources/adodb/adodb-php/session/old/adodb-cryptsession.php
>>> 189: global $$var;
>>>
>>> sources/adodb/adodb-php/session/old/adodb-session.php
>>> 300: global $$var;
>>>
>>> sources/adodb/adodb-php/session/old/adodb-session-clob.php
>>> 269: global $$var;
>>>
>>> sources/wp-cli/wp-cli/php/WP_CLI/Runner.php
>>> 1177: global ${$key};
>>>
>>>
>>> sources/apache/log4php/src/main/php/pattern/LoggerPatternConverterSuperglobal.php
>>> 71: global ${$this->name};
>>>
>>> We could deprecate this in favor of $GLOBALS, though as Dan said, the
>>> motivation is not quite clear right now.
>>>
>>> Nikita
>>>
>>

--00000000000046938105930f0fbd--