Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87940
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.181 as permitted sender)
To: internals@lists.php.net
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>
Message-ID: <55DE0907.6040904@gmail.com>
Date: Wed, 26 Aug 2015 19:44:23 +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: <8C74463E-DBA2-4015-8159-0B44D973387F@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 26/08/2015 18:07:
> I provide examples to help explain that I (and I suspect most developers) default to using isset which works on either.
>
> Just because there is a function, which does not exactly roll off the tongue (plus the fun of the needle/haystack ordering issue), does not mean it gets used (even if it is the correct thing to use).


That's all very well, but what is the Internals community supposed to do 
about it? Does the documentation need to be improved to point out that 
there is a better function to use for this case?

> I say "or key" because developers use the isset function on both $var and $var['key']... yes, I know they are different, but when you are coding in PHP an isset check is an isset check (well it isn't, because the variable may technically exist).
>
> If this is a problem, maybe PHP should raise a notice when isset is used on arrays?


It's only a problem in the same way that using file_exists() is a 
problem when you actually wanted the functionality of is_readable() - 
both functions exist, and it's not the language's responsibility to 
guess which you meant.



>>> where NULL may be a perfectly valid value.
>> It's not that NULL isn't a valid value; it's that "doesn't exist" isn't a meaningful state for a variable. It's like checking if the current line number is greater than 100, it shouldn't mean anything to the compiled program. See the SO answer I linked earlier for more thought experiments along these lines.
>
> I think you have been spending too much time in C.
>
> Most of the PHP code bases I've worked on set variables to NULL at some point (and they are not calling unset, because that isn't the intention).


Perhaps my double negative made it unclear, so I will restate: there is 
nothing wrong with setting a variable to NULL. There is also nothing 
wrong with calling unset() on a plain variable, e.g. to make it obvious 
to readers of the code that this variable should not be used below this 
point.

There IS something wrong with any code which needs to distinguish which 
of those two things happened, at run-time, because such code would be 
incredibly fragile and hard to follow.

You could, if you wanted, emulate a boolean variable by using $foo=null 
for true, and unset($foo) for false, but why not simply have a boolean 
variable?

[Incidentally, I know barely any C, but program PHP for a living.]

Regards,
-- 
Rowan Collins
[IMSoP]