Re: New RFC : empty() function

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. Improvements must be achieved, whatever they would cost. Ambiguities shall be resolved. I think this is the first principle in computer science: 0 or 1 ! :-D In any case, they are not assumed to be resort into cut-off transitions: they may be achieved within 3, 4 or 5 versions. Don't be scared. I have implemented my version in my own library and it works like a charm: you'll have exactly what you read. Alessandro Rosa Il giorno lun 30 ott 2023 alle ore 16:59 tag Knife <fenniclog@gmail.com> ha scritto: > > > > 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. > > > > trust me, Ive worked on some terrible code bases that do > exactly that and have variables redefined or dynamically assigned > and you have to really check if it has been assigned a value or > not and what value. > > It might be forgotten by everyone because of how far PHP has come > but there is still extensive use of the @ suppressor and the > alternative to empty would be > > if (@$var == "" || @$var == null || @$var == [] || count(@$var) == 0){} > > > empty() is 1 of 3 functions i believe that does not throw an undefined > variable warning if you don't @ suppress the variable you are passing in. > > So if you want to get rid of empty, can we reignite the talks to finally > get rid of @ >