Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88241
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>
 <op.x40kc9k9huszwh@tsukapiou.home>
Message-ID: <55F97251.3080706@gmail.com>
Date: Wed, 16 Sep 2015 14:44:49 +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: <op.x40kc9k9huszwh@tsukapiou.home>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: PHP 7.1 - Address PHPSadness #28?
From: rowan.collins@gmail.com (Rowan Collins)

Benoit Schildknecht wrote on 15/09/2015 18:04:

> Every dev I've seen in my company use isset() as its name says it does 
> : "Is this variable set, whatever its value is ?". That's exactly how 
> we use it in the code.

Can you give an example of code where you do not know this until the 
code runs - i.e. where "is this variable set?" is something you can hang 
business logic on?

Somewhere where it would make sense to write something like this, if the 
exists() function were available for plain variables:

if ( exists($a) ) {
...
} elseif ( is_null($a) ) {
...
} else {
...
}


> The irony is, we set a variable to "null" mostly to avoid "Undefined 
> variable" notices. To explain it shortly, when we see "$var = null;", 
> we know that it is a variable that could not be changed in the scope. 

Why is that ironic? That's exactly what the notice is telling you to do 
- assign an explicit value to your variables to say "this variable 
intentionally left blank".


> It is logical (at least for us) that "isset()" returns true when a 
> variable exists, even if its value is "null". I've yet to discover a 
> security bug in our code, but we have very sensitive applications, in 
> which we widely use "isset()". It could cause a lot of damages (maybe 
> it already has, but haven't noticed yet), and "exists()" would prevent 
> them. 

Again, I challenge you - or anyone - to give a single, theoretical, 
example of such a bug. The only ones I can think of are made worse by 
use of exists(), not better, because they allow programmers to write 
extremely brittle code, as in the example I posted earlier of 
refactoring to extract code into a new function:

...
unset($foo);
refactored_code($foo);
...

function refactored_code($bar)
{
     if exists($bar) // oops, this is always true
     ...
}


This is why I'm so opposed to the suggestion, because not only can 
people use it to write really bad code, I've yet to see an example where 
it would lead to good code. If we're interested in the reputation of the 
language, adding facilities for doing things badly doesn't sound like a 
good move.

Regards,
-- 
Rowan Collins
[IMSoP]