Re: PHP 7.1 - Address PHPSadness #28?

From: 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] >

« previous php.internals (#88126) next »