Thanks everybody for joining this discussion. I appreciated a lot the points you raised, as they are helping me to update and improve my rfc, whose meaning, as I hope, would look clearer than the earlier version.
Alessandro Il giorno lun 30 ott 2023 alle ore 16:36 Lynn <kja...@gmail.com> ha scritto: > On Mon, Oct 30, 2023 at 4:21 PM tag Knife <fennic...@gmail.com> wrote: > > > > > > > However, according to my example, the variable is defined and has its > > > value as 0 or false, and empty() returns true anyway. I confess that > > > I've had some problems like this, and we chose not to use empty(), as > > > sometimes 0 or false makes sense as a valid value. > > > > > > > That is exactly as the documentation explains it. > > empty is to check if a variable is not holding a usable value. > > 0, false, true are all valid values and show the variable is not > > empty. > > > > The purpose for empty is to check for undefined variables, empty > > arrays or empty strings. > > eg. "", [], null or undefined. > > > > This is exactly where the problem lies. Is a string with just whitespace > empty? Why would an ArrayObject with count 0 not be considered to be empty > while an array with count 0 is? "empty" is subjective and therefore not a > reliable function to use. Especially in legacy code I find that people use > `empty` where they should've been using `count() === 0` and have resulted > in bugs that weren't discovered until months or years later. The variations > of `$a === ''`, `count($a) === 0`, `! isset($a)`, and `$a === null` already > check all the scenarios you need, without risking funky bugs due to how the > internal check for "falsy" values works. >
