Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88436
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.169 as permitted sender)
To: internals@lists.php.net
References: <CAKws9z27kVJ87Ur5Qo+ayYHPeeO=aYKpRHUV4TFBXX2iMcgO2A@mail.gmail.com>
 <55FB4270.7000204@lsces.co.uk> <55FB4969.7080600@gmail.com>
 <55FB5BA6.6050606@lsces.co.uk> <55FBF265.5000502@gmail.com>
 <55FBF7B7.4050603@lsces.co.uk> <55FC1A77.7090406@gmail.com>
 <55FC221A.7020108@lsces.co.uk> <55FC2588.6030809@gmail.com>
 <55FC2B17.3070909@lsces.co.uk> <55FC2F2F.9060403@gmail.com>
 <55FC33F1.3090903@lsces.co.uk> <55FC354B.5070209@gmail.com>
 <55FC39B2.5070005@lsces.co.uk> <55FC45C7.9010202@gmail.com>
 <55FC4991.1050903@lsces.co.uk>
 <7872E9F4-AE19-4681-B2EF-215751AE4CBE@thesba.com>
 <op.x4573wqthuszwh@tsukapiou.home> <55FC5A14.8020301@gmail.com>
 <op.x46bf5grhuszwh@tsukapiou.home>
 <BAAC6F1B-3DDC-4D0C-8802-3B8210AEF13E@gmail.com>
 <55FC8D53.3080904@lsces.co.uk>
 <93020C79-3920-4FC8-8B6B-F1D16C6C709C@gmail.com>
 <55FD7613.1080403@lsces.co.uk>
 <9B86E351-089D-4356-BC8A-F683BA31D1A8@gmail.com>
 <EEB103A9-DA8C-4025-B06A-75925095BACC@php.net> <5602778C.2070205@gmail.com>
 <56027EC6.1020206@lsces.co.uk>
Message-ID: <560281B9.5050808@gmail.com>
Date: Wed, 23 Sep 2015 11:40:57 +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: <56027EC6.1020206@lsces.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
From: rowan.collins@gmail.com (Rowan Collins)

Lester Caine wrote on 23/09/2015 11:28:
> Yes from one point of view the
> problem is not with is_null() and I can agree with that. The problem is
> that one can't establish that a call to is_null() is going to access a
> valid variable while only working in the simple procedural layer.

You can't establish that a call to any function is going to access a 
valid variable (other than the way Michael mentioned). It really has 
nothing to do with is_null(), and therefore with the notices that 
is_null() emits.


> exists() -> empty() or is_null() answers all cases and isset() is
> redundant but for BC reasons can't be removed.

Lots of functions are redundant in that they can be built using other 
functions. I don't see "if ( exists($foo) && ! is_null($foo) )" as an 
improvement over "if ( isset($foo) )" for the extremely common case 
where you don't want or need any distinction between the two states, though.


> Using isset() in place of exists() is NOT a valid substitution since one
> can't then call is_null() KNOWING that the variable does exist.

I think you're flogging a dead horse here. We all agree that isset() 
does not check for variable existence.

Also, calling both isset() and is_null() on the same variable is 
entirely pointless, because they both make exactly the same check. "if ( 
isset($foo) && is_null($foo) )" can be simplified to "if ( false )".


> we have hopefully established that the null state is a natural
> result of interaction with a database

Indeed, I have never disputed that. A non-existent variable, however, is 
not something I've ever come across in a database context - it would 
seem to require a result set having rows with different numbers of columns.


Regards,
-- 
Rowan Collins
[IMSoP]