On 7 September 2015 14:11:05 BST, Craig Francis <cr...@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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
