Re: PHP 7.1 - Address PHPSadness #28?
| From: | Craig Francis | Date: | Wed, 09 Sep 2015 15:54:37 +0000 |
| Subject: | Re: PHP 7.1 - Address PHPSadness #28? | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-88126@lists.php.net to get a copy of this message | ||
On 8 Sep 2015, at 19:22, Rowan Collins <rowan.collins@gmail.com> 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 <rowan.collins@gmail.com> wrote:
> 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]
>