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

From: Date: Sat, 18 Apr 2015 15:33:55 +0000
Subject: Bug #69476 [Com]: is_null() must not throw warnings
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-192191@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 Comment by: Rowan dot Collins at gmail dot com 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: There is a Stack Overflow question discussing this at length here: http://stackoverflow.com/q/418066/157957 If you are dynamically defining array keys or object properties, array_key_exists and property_exists allow you to check their existence regardless of value. Dynamically defining actual variables is possible, but universally worse than using an array or object container, so does not require language support. This leaves only the case where you don't know if a variable has been *initialised*; since an uninitialised variable is considered to have the value null, a variable set to null is considered the same as one which hasn't been initialised. This is consistent, well-documented, and reasonable behaviour. It may not be the behaviour you would LIKE, but insulting people on a public bug tracker is not going to convince them a change is needed. Previous Comments: ------------------------------------------------------------------------ [2015-04-17 18:20:11] spam2 at rhsoft dot net and BTW you at your own did not understand the PHP behavior, otherwise you would not have reommended "isset($var) && !is_null($var)" while "isset() && is_null()" is just impossible and so the && construct makes no sense ------------------------------------------------------------------------ [2015-04-17 18:18:02] spam2 at rhsoft dot net well, you can't seriously claim wrong behavior correct just beause millions of programmers learned to deal with the inconsistent und unexpected behavior left and right all over the programming language ------------------------------------------------------------------------ [2015-04-17 18:15:15] cmb@php.net Harald, please reconsider your attitude. Claiming that the behavior of isset is braindead, while it obviously works well for millions of programmers, and even ranting and cursing, is certainly unrewarding. :) If you really consider it necessary to change the behavior or, more realistically, introduce a new language construct, feel free to propose a respective RFC; see the instructions in the Wiki on how to do so[1]. [1] <https://wiki.php.net/rfc/howto> ------------------------------------------------------------------------ [2015-04-17 17:45:30] spam2 at rhsoft dot net > 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 ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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 (#192191) next »