Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88435
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
To: internals@lists.php.net
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>
 <EEB103A9-DA8C-4025-B06A-75925095BACC@php.net> <5602778C.2070205@gmail.com>
Message-ID: <56027EC6.1020206@lsces.co.uk>
Date: Wed, 23 Sep 2015 11:28:22 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <5602778C.2070205@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
From: lester@lsces.co.uk (Lester Caine)

On 23/09/15 10:57, Rowan Collins wrote:
>> array_key_exists(“var”, get_defined_vars()) && is_null($var)
> 
> I wondered if someone would mention that, but didn't want to drift too
> far from the point, which was the "prior to call is_null()" part of
> Lester's sentence was redundant, since the problem was entirely
> unrelated to is_null().

That the more modern way of working would be to perhaps remain in the
'associative array' space is a fact. Using expand() and then rebuilding
the expanded array along with all the other variables seems an even more
torturous fix to a simple problem. 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. While
'exists()' may seem to be unnecessary, it returns an answer which makes
subsequent work flow a LOT more consistent.

exists() -> empty() or is_null() answers all cases and isset() is
redundant but for BC reasons can't be removed.

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. If the
variables are being created - or not - in this program flow, then a
check for exists() will establish if the variable needs creating, while
isset() will miss and overwrite a variable if it was quite legitimately
already created as null. If the default state is 'null' then there is
not a problem, but if that null is trying to override another default
... we have hopefully established that the null state is a natural
result of interaction with a database, but PHP has lost some of that
special handling by simply treating it as 'just another value' as now
happens by namespaces being able to override it.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk