Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88353
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
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>
Date: Fri, 18 Sep 2015 21:37:07 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: Quoted-Printable
Message-ID: <op.x46bf5grhuszwh@tsukapiou.home>
User-Agent: Opera Mail/1.0 (Win32)
Subject: Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
From: bensor987@neuf.fr ("Benoit Schildknecht")

Le Fri, 18 Sep 2015 20:38:12 +0200, Rowan Collins  =

<rowan.collins@gmail.com> a =C3=A9crit:

> Benoit Schildknecht wrote on 18/09/2015 19:24:
>> I agree. exists() would allow PHP devs to make more secure, cleaner a=
nd  =

>> lighter code. It fills a gap and would be useful to a lot of devs.
>
> On the contrary, I think code using exists() would be extremely fragil=
e,  =

> because it's highly resistant to refactoring, and encourages developer=
s  =

> to leave variables uninitialised.
>
> What makes cleaner, more secure code is always initialising your  =

> variables before using them - basically, what the "undefined variable"=
  =

> Notice is suggesting you do.
>
> The examples Lester and Robert have come up with make sense in  =

> themselves, but are not architectures I would choose precisely because=
  =

> they are opaque (you have to remember what unset() and null mean) and =
 =

> hard to extend (there's no way to introduce a 4th state alongside the =
 =

> unset/null/value triad).
>
> Obviously, all language features can be used to write bad code, but it=
  =

> seems much easier to write bad code than good using this proposed  =

> function.
>
> Regards,

So there is a bug regarding variables and null. Because I don't get any =
 =

notice if I use a variable with "null" as a value. If "null" means  =

"uninitialized", how come there are no notices ?
<?php
echo $foo;//Notice
$foo =3D null;
echo $foo;//No Notice

And how come the null variable appear in get_defined_vars(), and disappe=
ar  =

after an unset() ? Because null !=3D undefined. The engine seems to cons=
ider  =

null as a distinct state. Something that is not undefined. It is already=
  =

like that, we are not theorizing.
<?php
var_dump(get_defined_vars()); // No traces of $foo
$foo =3D null;
var_dump(get_defined_vars()); // ["foo"] =3D> NULL
unset($foo);
var_dump(get_defined_vars()); // Good bye, foo

You have a lot of people who use isset() against null elements in an  =

array. null elements happen a lot when interacting with an SQL server (f=
or  =

instance). I personally use array_key_exists(), but most people won't do=
  =

the same at all. Because they think it is the same. And they'll forget, =
 =

because isset() behaviour doesn't make sense, since null doesn't exactly=
  =

behave as you say.

Using is_null() against a var to see if it is set and has a null value  =

WILL trigger notices, and that's clearly not clean at all. In a producti=
on  =

environment, you would like to get rid of them. All of them.

Taking advantage of set_error_handler() is out of question : how can you=
  =

know if the triggered notice is related to a variable you expected to be=
  =

declared with null ? Very hard task (if not impossible), and very heavy =
to  =

implement.

And you have webservices, cURL, JSON, etc... All of these can give you  =

"null" values. And it is not rare. This is not something we can correct.=
  =

We have no control on this.

There are way more cases in which exists() would improve things A LOT. W=
e  =

need a native function that allows us to check this state WITHOUT  =

triggering a notice.

Regards,