Bug #69476 [Nab]: is_null() must not throw warnings

From: Date: Fri, 17 Apr 2015 17:45:31 +0000
Subject: Bug #69476 [Nab]: is_null() must not throw warnings
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-192165@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=69476&edit=1 ID: 69476 User updated by: spam2 at rhsoft dot net Reported by: spam2 at rhsoft dot net Summary: is_null() must not throw warnings Status: Not a bug Type: Bug Package: Scripting Engine problem Operating System: Linux PHP Version: Irrelevant Block user comment: N Private report: N New Comment: > If this does not satisfy your use-case you refuse to understand that such pervert behavior is not a matter of a use-case - it's a matter of a clean and expectable language behavior i don't have a usecase, i was just asked today what isset() in case of NULL gives back and i answered true just because of logical thinking that the variable is defined and so set > The behavior of is_null() can not change either, > as it is an ordinary function, not a language construct and how does that matter in the context of not idiotically throw warnings in case of a undefined variable instead just return false since it don't have the value NULL and so make it at least *possible* to distinct between a undefined variable or NULL as value Previous Comments: ------------------------------------------------------------------------ [2015-04-17 17:37:26] nikic@php.net Indeed, isset() behaves the same for array keys and object properties. I was merely pointing out that for these usages there are alternatives like array_key_exists(), which will return true even if the value is null. If this does not satisfy your use-case, you're out of luck. The behavior of isset() will not change. The behavior of is_null() can not change either, as it is an ordinary function, not a language construct. ------------------------------------------------------------------------ [2015-04-17 17:28:29] spam2 at rhsoft dot net > it exists so you can write isset($array['key']) but it don't work relieable because in case of the key existing but NULL as value it gives back false which is pure bullshit - frankly speaking my breath was away as your answers implied isset() in case of a array-key and a simple variable again behaves different, at least that is not the case - it's the same way wrong [harry@srv-rhsoft:~]$ cat test.php <?php $x = array(); $x['a'] = NULL; if(isset($x['a'])) { echo "DEFINED\n"; } else { echo "UNDEFINED\n"; } $y = NULL; if(isset($y)) { echo "DEFNINED\n"; } else { echo "UNDEFINED\n"; } ------------------------------------------------------------------------ [2015-04-17 17:20:51] spam2 at rhsoft dot net practically speaking the only fishy is a programming language with such illogical inconsistency not following the rule of least suprise and that *is* a bug which you can't discuss away with "i don't know why someone would write code like this" - that someone can expect a sane and logical behavior ------------------------------------------------------------------------ [2015-04-17 17:13:23] nikic@php.net > well, why does isset() exists with your logic? Practically speaking, it exists so you can write isset($array['key']). This is the primary use-case for isset(). Writing isset($array), which implies that you do not know if a variable exists, sounds rather fishy to me, thus my inquiring as to your particular use-case that is supposed to require distinguishing between undefined and null for simple variables. ------------------------------------------------------------------------ [2015-04-17 17:03:14] spam2 at rhsoft dot net > Could you please describe why you consider this to be necessary? well, why does isset() exists with your logic? - it is necessary because the isset() behavior is braindead return false in case of NULL - if i want that behavior i would just use empty() the whole purpose of isset() is to check if a variable is defined the whole purpose if is_null() is to work around broken isset() behavior and no - put a @ in front is not a clean coding style ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=69476 -- Edit this bug report at https://bugs.php.net/bug.php?id=69476&edit=1

« previous php.bugs (#192165) next »