On 8 Sep 2015, at 19:22, Rowan Collins <[email protected]> wrote:
> 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.
I don't think it is an odd thing to suppress a warning for a plain variable.
For example, on a blog you may have a list of articles, which is used by both
the admin and users, but the (MVC) controller might set an $add_url, so a link
to add a new article can be displayed...
Controller:
if (IS_ADMIN) {
$this->set('add_url', '/admin/articles/add/');
}
View:
<?php if (exists($add_url)) { ?>
<p><a href="<?= html($add_url) ?>">Add article</a>
<?php } ?>
Admittedly in this case the controller could be updated to something like the
following:
$this->set('add_url', (IS_ADMIN ? '/admin/blog/add/' : NULL));
But it gets more complicated when you can have multiple things appearing (or
not) on a page.
> 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.
I completely agree that we shouldn't be adding more functions lightly, and it's
why I'm still not completely sold on the idea myself.
I think the main two negatives is adding yet another function (confusion), and
that it will take a long time before developers can use it everywhere.
But, the thing that wins it over for me is that isset() seems to be (mis)used
by a lot of developers as a function to check if the variable exists (not that
the variable has a value).
So if implemented, in a few years (decades?), I suspect the exists() function
would be the first function that comes to mind, instead of array_key_exists()
and isset().
Actually, in a few years time, if developers did their NULL checks with "===
NULL", then isset(), is_null(), array_key_exists(), and empty() could all be
deprecated :-)
Craig
On 8 Sep 2015, at 19:22, Rowan Collins <[email protected]> wrote:
> On 7 September 2015 14:11:05 BST, Craig Francis <[email protected]>
> 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
