Re: PHP 7.1 - Address PHPSadness #28?

From: Date: Fri, 18 Sep 2015 23:04:46 +0000
Subject: Re: PHP 7.1 - Address PHPSadness #28?
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20  Groups: php.internals 
Request: Send a blank email to internals+get-88366@lists.php.net to get a copy of this message
Hi Rowan, Le 18/09/2015 22:32, Rowan Collins a écrit :
It's the other way around - null doesn't mean uninitialized, but an uninitialized variable has the implicit value null. It's also a reasonably likely sign that there's a bug in your code, so PHP gives you a notice suggesting you set it explicitly before reading from it.
I think we got the point now ;)... and it seems eveyone except you and Stas disagree on the way you understand this. I guess 99.9 % of PHP devs would tell you that accessing an uninitialized variable triggers an error. You can argue that a 'notice' is not an error but, in practice, everybody considers it this way. Nobody will tell you : 'Oh, that's just a notice, just disable E_NOTICE in your php.ini'. As I already said, IMO, modifying the documentation to say "Warning: using isset() instead of array_key_exists() to test whether an array element exists will send you to hell." won't change anything. People currently writing 'isset($foo['bar'])' won't change it for 'array_key_exists('bar',$foo)'. Just because it is longer, less readable, and you need to remember argument order (which is quite counter-intuitive). So, as everyone seems to have exposed his arguments, I think we need an RFC and a patch now. Unless anyone volunteers, I'll write the patch. Who can write the RFC ? Robert ? Regards François

« previous php.internals (#88366) next »