Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88119
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.172 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <E1C02A1A-EB7C-40D9-8760-13627CC7BF85@craigfrancis.co.uk>
References: <CAKws9z27kVJ87Ur5Qo+ayYHPeeO=aYKpRHUV4TFBXX2iMcgO2A@mail.gmail.com> <55DD4269.4090402@gmail.com> <6348DFA7-04BD-41BB-A500-17A8A531B56C@craigfrancis.co.uk> <55DDA4C9.9040603@gmail.com> <3C69BF4B-52E6-4D04-8601-8D23DFCC538E@craigfrancis.co.uk> <55DDD60F.5090509@gmail.com> <8C74463E-DBA2-4015-8159-0B44D973387F@craigfrancis.co.uk> <55DE0907.6040904@gmail.com> <1F615BCD-1B9B-4C51-A210-869F1AA1F6E3@craigfrancis.co.uk> <55E5EBBF.6020803@gmail.com> <0BA3A129-D356-4781-B6DE-E2B5A7924AE2@craigfrancis.co.uk> <55E6EC36.6090301@gmail.com> <E1C02A1A-EB7C-40D9-8760-13627CC7BF85@craigfrancis.co.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Tue, 08 Sep 2015 19:22:46 +0100
To: Craig Francis <craig@craigfrancis.co.uk>
CC: internals@lists.php.net
Message-ID: <9AF329EC-99A5-412D-A52B-432627A5520F@gmail.com>
Subject: Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
From: rowan.collins@gmail.com (Rowan Collins)

On 7 September 2015 14:11:05 BST, Craig Francis <craig@craigfrancis.co.uk> wrote:

>But then again, I don't think it's a quirk that "you don't get a
>warning when passing a completely undefined variable to isset()", as I
>don't see isset() as a normal function.

What I meant is that people seem to interpret isset() as having a special case for null values, and want that special case to go away. I was suggesting you could instead see it as a version of is_null with a special case to stop it complaining about non-existent variables. This makes sense, since in practice a "non-existent" variable (note: not array item or property) always has the value "null".

It's also a "quirk" in the sense that suppressing that warning for a plain variable is an odd thing to want - if you've assigned meaning to that variable you should be initialising it somewhere so that your code is more readable and less fragile.


>With the `exists($foo['bar']['baz'])` example, I just see that as a
>simple: if $foo exists, and contains the key 'bar', and contains the
>key 'baz' (no need to check values).
>
>Like isset() I see exists() as a special function that isn't passing a
>variable in, but PHP doing some analysis of the thing in the brackets.

OK, thinking about it some more, I can see it would be convenient to have a special syntax for array_key_exists() which looked the same as a normal array-index access; basically some magic parser rule that turned exists($foo['bar']) into array_key_exists($foo, 'bar') Looking at the generated opcodes, that could indeed be quite similar to how isset() works internally. 

If such a function/syntax were built, I would argue that a plain exists($foo) should be a parse error, because there is no key to check, only a single value - it would be equivalent to array_key_exists($foo, null) or array_key_exists(null, $foo). For that reason, it should probably have a name that made its purpose clearer, too, but I'm not sure what that would be.

I admit this does partly come down to pre-judging any code that would use empty($foo) as "bad", but the warning issued when you access an uninitialised variable already makes such a judgement. And if people are already confused by the relationship between isset() is_null(), empty(), etc, adding yet another variant is likely to hurt rather than help.

Regards,
-- 
Rowan Collins
[IMSoP]