Hi Mr. Wetherington,
thanks for appreciating my proposal.
According to the contents of my RFC under discussion,
I suppose my version works better than the code you presented.
The RFC contents do illustrate the details of the performance as well as
some examples have been included.
For what concerns the implementation, I __just__ suggested deprecation.
Both empty() and is_empty() may co-live.
Regards,
Alessandro Rosa
Il giorno mar 31 ott 2023 alle ore 17:08 Brady Wetherington via internals <
internals@lists.php.net> ha scritto:
> > I have posted a new RFC at this link
> https://wiki.php.net/rfc/empty_function
> > where I suggested some improvements to the standard built-in empty()
> > function and provided a number of examples.
>
> Is your "is_empty()" function equivalent to something like:
>
> function is_empty($param = null)
> {
> return empty($param) && $param !== false && $param !== 0 && $param !==
> 0.0;
> }
>
> If so, that might actually be kinda nice? I was looking for something
> like that the other day.
>
> Regardless, I wouldn't do the BC-break; I'd be more inclined to (very
> begrudgingly) leave empty() and warn against its use, and have
> is_empty() as a new thing. Maybe for some future deprecation or
> removal?
>
> I also do like the idea that someone else mentioned here about being
> able to possibly start to get away from @'ing variables with a
> solution like this.
>
> -B.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
Il giorno mar 31 ott 2023 alle ore 17:08 Brady Wetherington via internals <
internals@lists.php.net> ha scritto:
