Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88383
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.195 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <55FDEFEC.80101@lsces.co.uk>
References: <CAKws9z27kVJ87Ur5Qo+ayYHPeeO=aYKpRHUV4TFBXX2iMcgO2A@mail.gmail.com>
	<55FB3A60.1040601@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>
	<55FDD71F.6070101@lsces.co.uk>
	<55FDDA0E.3050003@gmail.com>
	<55FDEFEC.80101@lsces.co.uk>
Date: Sat, 19 Sep 2015 18:43:06 -0600
Message-ID: <CAObuZdvG7FQDj224pOJGD-DiGimWtwyY8TgvLNucM+AzZWQ-9g@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: Rowan Collins <rowan.collins@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04428e5658a9770520230c1d
Subject: Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
From: derokorian@gmail.com (Ryan Pallas)

--f46d04428e5658a9770520230c1d
Content-Type: text/plain; charset=UTF-8

On Sat, Sep 19, 2015 at 5:29 PM, Lester Caine <lester@lsces.co.uk> wrote:

> On 19/09/15 22:56, Rowan Collins wrote:
> >>> If what you want to do is avoid the notice, then you don't need to
> >>> "find out before calling is_null", you need to call isset *instead
> >>> of* is_null. Again, ignore the name, and concentrate on what it
> >>> actually does.
> >> BUT ISSET RETURNS FALSE FOR A VARIABLE THAT IS SET BUT NULL ... END OF
> >> STORY ...
> >
> > AND SO DOES IS_NULL
> >
> > The notices emitted by is_null are COMPLETELY IRRELEVANT.
>
> ? is_null returns true if the variable exists and is NULL and throws a
> notice if the variable is not set WHY is that fact COMPLETELY
> IRRELEVANT? Just because you don't think people should be coding in the
> way that it causes problems with existing code does not make it
> irrelevant we have to put up with the notices because there is no CLEAN
> way to establish that a variable exists only that it is set.
>

I would also point out that is_null returns true (after the engine produces
a notice) for undefined variables:

$ php -r "var_dump(is_null($a));"

Notice: Undefined variable: a in Command line code on line 1

Call Stack:
     0.0001     118888    1. {main{() Command line code:0

*bool(true)*

So is_null does not help to determine if a plain variable is in fact null.

--f46d04428e5658a9770520230c1d--