Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87989
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain paragonie.com from 209.85.212.180 cause and error)
MIME-Version: 1.0
In-Reply-To: <1F615BCD-1B9B-4C51-A210-869F1AA1F6E3@craigfrancis.co.uk>
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>
	<55DE0907.6040904@gmail.com>
	<1F615BCD-1B9B-4C51-A210-869F1AA1F6E3@craigfrancis.co.uk>
Date: Tue, 1 Sep 2015 05:38:24 -0400
Message-ID: <CAKws9z29vSi0e5pNHC_snJPnbbOV9bi_6i=w4dxgm1Evpz=HVA@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: Rowan Collins <rowan.collins@gmail.com>, Ryan Pallas <derokorian@gmail.com>, 
	James Gilliland <neclimdul@gmail.com>, Bishop Bettini <bishop@php.net>, 
	Stanislav Malyshev <smalyshev@gmail.com>, Lester Caine <lester@lsces.co.uk>, 
	PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
From: scott@paragonie.com (Scott Arciszewski)

On Tue, Sep 1, 2015 at 5:29 AM, Craig Francis <craig@craigfrancis.co.uk> wr=
ote:
> Hi Rowan, Ryan, James, Bishop, Stas, Lester,
>
> I've been giving this some thought over the weekend, and I agree with wha=
t you are all saying, but I think there is an element of confusion in the P=
HP programming community that needs to be addressed (somehow).
>
> Yes, we probably should not be giving special meaning to NULL, as James m=
entions (although I probably still will).
>
> And to be fair, I still can't think of an example where isset() can be us=
ed on a standard variable. All my examples are really array based, and bett=
er addressed with array_key_exists() - where Rowan does a great job of expl=
aining the different examples on stackoverflow:
>
>   http://stackoverflow.com/a/18646568/2908724
>
> Trying to get to route of the confusion though, I think it might be down =
to how the code can be read. So if we take:
>
> <?php
>   $a =3D 1;
>   $b =3D NULL;
>   var_dump($a);
>   var_dump($b);
>   var_dump($c);
>   var_dump(isset($a));
>   var_dump(isset($b));
>   var_dump(isset($c));
> ?>
>
> Or using an array instead:
>
> <?php
>   $v['a'] =3D 1;
>   $v['b'] =3D NULL;
>   var_dump($v['a']);
>   var_dump($v['b']);
>   var_dump($v['c']);
>   var_dump(isset($v['a']));
>   var_dump(isset($v['b']));
>   var_dump(isset($v['c']));
> ?>
>
> In both cases (and ignoring the undefined variable error), we get:
>
>   int(1)
>   NULL
>   NULL
>
>   bool(true)
>   bool(false)
>   bool(false)
>
> But if we ignore the manual for a minute:
>
>   http://php.net/isset
>
> I think a good comparison to what that code reads as, vs what PHP does, c=
an be summarised as:
>
>   Read as: The variable is set (exists).
>
>   Executed as: The variables *value* is set.
>
> Where NULL is not considered a set value.
>
> So when we have:
>
>   if (isset($v['a'])) {
>   }
>
> It's not saying that the key 'a' is set (exists) on the array $v.
>
> Instead its saying that the key 'a' has a set value (not NULL) on the arr=
ay $v.
>
> Where this is made more of a common problem because there are many array_=
* functions, and they rarely come to mind when your not thinking of an arra=
y like operation.
>
> This situation might be improved by re-wording the manual a bit.
>
> Having headings like "This also work[s] for elements in arrays", makes it=
 sound all inclusive and *the* function to use.
>
> Whereas I'm starting to get the feeling that isset() is actually a functi=
on that probably should be avoided (I'll skip this tangent for now).
>
> Personally I still like the idea of an exists(), because I feel that is h=
ow many programmers treat and use the isset() function - simply because the=
y do use NULL as a valid value, and either haven't read the manual, or forg=
et the exception that is mentioned on line 1 (something I've done a couple =
of times).
>
> Although I realise it will take many years before anyone can start using =
it.
>
> Craig
>
>
>
>
>
>
>
>
> On 26 Aug 2015, at 19:44, Rowan Collins <rowan.collins@gmail.com> wrote:
>
>> Craig Francis wrote on 26/08/2015 18:07:
>>> I provide examples to help explain that I (and I suspect most developer=
s) default to using isset which works on either.
>>>
>>> Just because there is a function, which does not exactly roll off the t=
ongue (plus the fun of the needle/haystack ordering issue), does not mean i=
t 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 the=
re is a better function to use for this case?
>>
>>> I say "or key" because developers use the isset function on both $var a=
nd $var['key']... yes, I know they are different, but when you are coding i=
n 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 use=
d on arrays?
>>
>>
>> It's only a problem in the same way that using file_exists() is a proble=
m when you actually wanted the functionality of is_readable() - both functi=
ons exist, and it's not the language's responsibility to guess which you me=
ant.
>>
>>
>>
>>>>> 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 pro=
gram. 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 reader=
s 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 incre=
dibly fragile and hard to follow.
>>
>> You could, if you wanted, emulate a boolean variable by using $foo=3Dnul=
l for true, and unset($foo) for false, but why not simply have a boolean va=
riable?
>>
>> [Incidentally, I know barely any C, but program PHP for a living.]
>>
>> Regards,
>> --
>> Rowan Collins
>> [IMSoP]
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

The pieces are already in place, if this is a desired feature we just
have to bring them together.

* array_key_exists()
* get_defined_vars()

I do agree that it would be years before anyone got to use it (either
7.1.0 or 8.0.0). I don't see that as a bad thing, this was low-hanging
fruit.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>