Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107284 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 57998 invoked from network); 21 Sep 2019 21:09:00 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 21 Sep 2019 21:09:00 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 436DE2D1FE9 for ; Sat, 21 Sep 2019 11:47:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS36351 199.187.172.0/22 X-Spam-Virus: No Received: from tbjjbihbhebb.turbo-smtp.net (tbjjbihbhebb.turbo-smtp.net [199.187.174.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Sat, 21 Sep 2019 11:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=php.net; s=turbo-smtp; x=1569696433; h=DomainKey-Signature:Received: Received:MIME-Version:References:In-Reply-To:From:Date: Message-ID:Subject:To:Cc:Content-Type; bh=k96hAlAYOBDxGoDf4ILCW9 p5OrDUKzK/2ih0EHQf2WI=; b=aZ/+YfJaOtovPWIRJuFd/k3KwhJD/h/FMlzcvT +QgNBBzGGiefmt4OyF3BS+zf0a7NP8HJYaLrfICAnmu1W5B3nwdT9SIWJSboe1NW /i6fbMfBk4VpLgYMSCWN9iVse8P7/pVhhUems0MDQ+v7MuKDcJHEgRPlbLLJVftO QdiBA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=turbo-smtp; d=php.net; h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type; b=aRXbEJO+BoOaUJo+DBYOXbPGHPBdZwKr/uzp07wZo6wCKziNe3rhHQRup19rnf enGDhO9jYDMWLdRSdlYYhuY4aKtPmfy8vrFQv//c4Jz0pnkKoYhVWVxxasGP2KRC z2dum9Vvgq92J2d3dDH/QQ9b31oPTx86wVC0Xaw5p1BdQ=; Received: (qmail 4247 invoked from network); 21 Sep 2019 18:47:11 -0000 Received: X-TurboSMTP-Tracking: 5298124110 X-Gm-Message-State: APjAAAWig++LqXJy4Wta/8J2jNs31OS6BgMxhAijHRT6O2c2paSoWZFC xzFPYX+3kb6e4uLr+asAdD8LTwo5RyG7QRk1waM= X-Google-Smtp-Source: APXvYqwhrbG0j/BhtKWqCBYl/6gQr8Rk8XhMLLerw2LoJ6BwftqCnR9FMZ15ZzIfJZd84y6cF9yP+fvcwJGnTvsYbXM= X-Received: by 2002:aed:2469:: with SMTP id s38mr9700483qtc.190.1569091630657; Sat, 21 Sep 2019 11:47:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Sat, 21 Sep 2019 21:46:59 +0300 X-Gmail-Original-Message-Id: Message-ID: To: Kosit Supanyo Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000043f5410593149d42" X-Envelope-From: Subject: Re: [PHP-DEV] Question about `global` variable declaration From: zeev@php.net (Zeev Suraski) --00000000000043f5410593149d42 Content-Type: text/plain; charset="UTF-8" On Sat, Sep 21, 2019 at 6:18 PM Kosit Supanyo wrote: > Unlike var, public, static and others - 'global' is not a declaration of >> class structure, but a way to access global variables. > > > I know it is not and I think almost everyone knows that. As I said, I came > up with this by comparing to other declarations syntactically not > functionally, it is inconsistent in that way. I don't know how many PHP > developers out there know `global` can take variable variables but I my > guess is, very very little because there's no information about this > behavior of `global` in PHP manual > https://www.php.net/manual/en/language.variables.scope.php and I'd never > seen those forms of `global` in any projects/articles before. > I think you're raising two separate points: 1. The global statement is inconsistent with other similar statements. 2. It's not widely used and we should consider deprecating this behavior. Re: #1 - even though it may look similar, the global statement is fundamentally different from public/private/static and friends. It's not really a declaration - it's like Nikita said is a simple equivalent for writing $foo = &$GLOBALS['foo'] - and as such, is a runtime statement as opposed to a compile-time declaration like the others. So despite the superficial similarities, the differences between the two justify different behavior/allowed syntax. Re: #2 - the fact it's not documented is a fair point - but I'm not sure that in itself is cause for anything other than perhaps adding a quick note in the docs. People familiar with PHP's variable-variables functionality ( https://www.php.net/manual/en/language.variables.variable.php) will not find this behavior as inconsistent or otherwise surprising, I think. It does appear to be mentioned in some places (e.g. the O'Reilly PHP Cookbook, https://www.oreilly.com/library/view/php-cookbook/1565926811/ch06s12.html). I doubt there'll be a big impact if we were to deprecate this behavior - it doesn't appear very mainstream (and there's a simple workaround available through $GLOBALS) - but I don't see any gain to be had either. Zeev --00000000000043f5410593149d42--