Craig Francis wrote on 09/09/2015 16:54:
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 } ?>

I can see that this makes nice terse View code, and is a reasonable use of existing isset() - though I can't see it needs to be anything other than isset(), because if $add_url was null, you wouldn't want to echo anything.

Arguably, it would be better handled with the vars placed into an array rather than materialising as PHP variables. The helper functions defined by the framework (here assumed to be called exists() and html()) could then extract items from that array, making it just as succinct:

    <?php if (exists('add_url')) { ?>
        <p><a href="<?= html('add_url') ?>">Add article</a>
    <?php } ?>


Boom, no more worries about undefined variables.

I'm pretty sure this is how templating languages like Smarty and Twig work - "{$foo}" in Smarty compiles to something like "echo $this->vars['foo'];"

Presumably under the hood, the set() method in your example has to instead do some magic with variable variables - $$foo syntax - which is like the ugly cousin of an associative array. Either that, or eval(), which as everyone knows is evil()! :P


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).

Do you mean that it is misused with arrays? Because with plain variables it does exactly what it needs to do.

Or do you mean that developers are using unset() to represent a state distinct from null? Because if so, that is their mistake, not the subsequent use of isset(). I have yet to see a single use case where distinguishing between these two states is necessary or sensible.


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 :-)

- is_null() makes sense because it's a type-checking function: it goes with is_bool(), is_int(), etc. - empty() is a bit odd because it's basically an inverted boolean cast, but does make quite readable code. - You've just demonstrated yourself a situation where isset() can't be replaced with === null or is_null() because you want to suppress the Notice. - I am fundamentally opposed to a function which distinguishes between unset($foo) and $foo=null for reasons I have stated several times.

So the only thing left is replacing array_key_exists with some nicer syntax so you can write some_keyword($foo['bar']) rather than array_key_exists('bar', $foo)

Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to