Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88478
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
References: <CAKws9z27kVJ87Ur5Qo+ayYHPeeO=aYKpRHUV4TFBXX2iMcgO2A@mail.gmail.com>
 <55E5EBBF.6020803@gmail.com>
 <0BA3A129-D356-4781-B6DE-E2B5A7924AE2@craigfrancis.co.uk>
 <55E6EC36.6090301@gmail.com>
 <E1C02A1A-EB7C-40D9-8760-13627CC7BF85@craigfrancis.co.uk>
 <9AF329EC-99A5-412D-A52B-432627A5520F@gmail.com>
 <6F4D91EE-B56E-4B83-B1AF-598C3F6897FC@craigfrancis.co.uk>
 <55F07BA4.2000204@gmail.com>
 <E8634CF1-C2B4-4C5A-8DDC-531D9599774B@craigfrancis.co.uk>
 <55F6B911.9080400@gmail.com>
 <96BE7F01-D04B-483B-B1A3-B45CED6DFCDC@craigfrancis.co.uk>
 <55F6F08C.1020506@gmail.com>
 <0BEF6D82-CB5F-49F6-A3A4-3267924A0CDA@thesba.com> <56009C96.5090504@php.net>
 <56013228.50504@gmail.com> <5601E01E.6080606@php.net>
 <56027C79.9020404@gmail.com> <5602BFB3.7090707@php.net>
 <CABM2syvWMhiH-HE=BH=J7DTACsS_83VNt7K=-mKTkifgg+J=LA@mail.gmail.com>
 <5602DE27.4080500@lsces.co.uk> <5602EEF8.2090500@gmail.com>
 <CAObuZdvqnvcQH0EjUbZdCwvC0WZZeDF-dhK2EMtm2h3h9dmQ6w@mail.gmail.com>
 <D85938EC-871C-41CD-965E-63DC30417E05@gmail.com>
To: PHP Internals <internals@lists.php.net>
Message-ID: <560435F2.4030408@gmail.com>
Date: Thu, 24 Sep 2015 18:42:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <D85938EC-871C-41CD-965E-63DC30417E05@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
From: rowan.collins@gmail.com (Rowan Collins)

Rowan Collins wrote on 23/09/2015 21:15:
> On 23 September 2015 20:04:57 BST, Ryan Pallas <derokorian@gmail.com> wrote:
>> I dislike this because it makes refactoring harder.
> What's more, the function is not dereferencing a variable to get its value, it is looking up a name in the symbol table, so the magic syntax that makes it look like you're using the variable is misleading.


Talking of refactoring, I thought of an interesting example of the 
ambiguity/confusion a combined exists() function could create.

For any normal function the two definitions below should be equivalent - 
you can refactor the use of $GLOBALS by importing the variable with the 
"global" keyword.

function foo() { var_dump(exists($GLOBALS['test'])); }
function bar() { global $test; var_dump(exists($test)); }

I haven't actually built François's branch to test, but based on 
behaviour of existing functions [e.g. https://3v4l.org/X0tOk], I predict 
the following output:

foo();
// bool(false)
bar();
// bool(true)

The "global $test" is the closest PHP comes to a variable declaration - 
the variable now exists in the symbol table, even though there was no 
global variable with that name to import.

Even more confusingly, it has a side-effect on the original function:

foo();
// bool(true)

That happens because "global $test" is basically "$test =& 
$GLOBALS['test']", so has to create the global variable in order to 
reference it. This is completely invisible to most programs, because it 
gets initialised to null, so isset() returns false consistently. 
[https://3v4l.org/f4dm2]

This is the kind of odd edge-case you end up with when you a) treat a 
variable's existence as an accessible property; and b) make that check 
appear to be the same as checking for an item in an array.


With the two functions I've proposed, you at least wouldn't be led 
astray by an automated refactoring tool because this would give an 
error, rather than a surprising result:

function bar() { global $test; var_dump(hasitem($test)); }

And you would have to specifically change it to this instead, clearly a 
different type of test:

function bar() { global $test; var_dump(variable_exists('test')); }


Regards,
-- 
Rowan Collins
[IMSoP]