Re: PHP 7.1 - Address PHPSadness #28?
| From: | Rowan Collins | Date: | Wed, 16 Sep 2015 14:01:29 +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-88243@lists.php.net to get a copy of this message | ||
Robert Williams wrote on 15/09/2015 10:38:
Okay, so to bring this home: 1 PHP defines null to include variables that have "not been set" 2 PHP also defines null to include variables that have been unset() 3 Variables can be explicitly set to null All of these are null. And yet: 4 Calling isset(), which is documented to return true on null, on 1, 2, and 3 will only return true for 3. How's this consistent?What you've just described there is the functionality some people want to add. Currently, isset() will return false for all three cases, precisely because they are treated as equivalent. So you've actually neatly demonstrated why it is consistent for isset() to behave as it does.
IMHO, PHP went south in its design when it tried to declare undefined variables as null. They're not; they're undefined. Beyond isset/empty/is_null, however, the rest of PHP seems to accept this."The rest of PHP" makes no such distinction. If you evaluate "$b = $a + 1" when $a is not defined, PHP behaves exactly as if you had written "$a=null; $b = (int)$a + 1;", but the runtime will issue a notice (not, as you keep claiming, an error) that you forgot to write the "$a=null" part and might want to add it in or check if you've mistyped the variable name. Regards, -- Rowan Collins [IMSoP]