Re: New RFC : empty() function

Hi there, it's a legacy function, and I don't think we can afford or we should consider this bc break. Though I don't use this function myself and also prefer other methods of input validation, still there are a lot of people that use it. Renaming this to is_empty will bring a bc break. However, the improvements to this function are worth considering. Ahmad On 10/30/23, Alessandro Rosa <alessandro.a.rosa@gmail.com> wrote: > 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 @ >> >