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.r...@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 <fennic...@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 @
>>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
