Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88127
Return-Path: <rowan.collins@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 84205 invoked from network); 9 Sep 2015 18:34:27 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 9 Sep 2015 18:34:27 -0000
Authentication-Results: pb1.pair.com smtp.mail=rowan.collins@gmail.com; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=rowan.collins@gmail.com; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
X-PHP-List-Original-Sender: rowan.collins@gmail.com
X-Host-Fingerprint: 209.85.212.182 mail-wi0-f182.google.com  
Received: from [209.85.212.182] ([209.85.212.182:36600] helo=mail-wi0-f182.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id F6/00-18051-2BB70F55 for <internals@lists.php.net>; Wed, 09 Sep 2015 14:34:27 -0400
Received: by wicgb1 with SMTP id gb1so127200197wic.1
        for <internals@lists.php.net>; Wed, 09 Sep 2015 11:34:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=subject:to:references:cc:from:message-id:date:user-agent
         :mime-version:in-reply-to:content-type:content-transfer-encoding;
        bh=HeZmVEVQRKUR29h0MhioLJG9Um+lN/tFU/oEmIb8Mes=;
        b=jgvz1hEnaYzX3Qd9WP6nN+UMyIK3zkAZ6RabM7Kpu42qDHHPl4cE6x55CbSYTY2PNq
         iGyYpluc2/jjUIHxDxB3fbWWYsrfAt9PrccSJ9iis84DfZjqeYIZ/DeTahV3YlZV0lyo
         UWTUfFOJHTgUeAkKnvPV0ZM421Kn+KsaUh8qs+yQBCPU08VWFAMZYgd3LvAybZAkYJHk
         KV9fgUIjLyi5gAtbeuO1F0B4ZINsgkgw0Bjysxkd0wc+5GbMoym5FNCPeqVus1iawgGe
         8hCR4bOfnTVcs4uTnVgRDqH7YEeN527/WmDEvGkRuu0jETE1ckn7XNg1Q17XmD2mdP+U
         oV6Q==
X-Received: by 10.180.90.107 with SMTP id bv11mr59923782wib.69.1441823663912;
        Wed, 09 Sep 2015 11:34:23 -0700 (PDT)
Received: from [192.168.0.134] ([62.189.198.114])
        by smtp.googlemail.com with ESMTPSA id d1sm5196669wiz.0.2015.09.09.11.34.22
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Wed, 09 Sep 2015 11:34:23 -0700 (PDT)
To: Craig Francis <craig@craigfrancis.co.uk>
References: <CAKws9z27kVJ87Ur5Qo+ayYHPeeO=aYKpRHUV4TFBXX2iMcgO2A@mail.gmail.com>
 <55DD4269.4090402@gmail.com>
 <6348DFA7-04BD-41BB-A500-17A8A531B56C@craigfrancis.co.uk>
 <55DDA4C9.9040603@gmail.com>
 <3C69BF4B-52E6-4D04-8601-8D23DFCC538E@craigfrancis.co.uk>
 <55DDD60F.5090509@gmail.com>
 <8C74463E-DBA2-4015-8159-0B44D973387F@craigfrancis.co.uk>
 <55DE0907.6040904@gmail.com>
 <1F615BCD-1B9B-4C51-A210-869F1AA1F6E3@craigfrancis.co.uk>
 <55E5EBBF.6020803@gmail.com>
 <0BA3A129-D356-4781-B6DE-E2B5A7924AE2@craigfrancis.co.uk>
 <55E6EC36.6090301@gmail.com>
 <E1C02A1A-EB7C-40D9-8760-13627CC7BF85@craigfrancis.co.uk>
 <9AF329EC-99A5-412D-A52B-432627A5520F@gmail.com>
 <6F4D91EE-B56E-4B83-B1AF-598C3F6897FC@craigfrancis.co.uk>
Cc: internals@lists.php.net
Message-ID: <55F07BA4.2000204@gmail.com>
Date: Wed, 9 Sep 2015 19:34:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <6F4D91EE-B56E-4B83-B1AF-598C3F6897FC@craigfrancis.co.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
From: rowan.collins@gmail.com (Rowan Collins)

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]