Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123499
Precedence: bulk
MIME-Version: 1.0
References: <CAB8mrRzG3UDUSKiwNN1+XNDuD-BX-15qCBppmCkvrehLavtaxw@mail.gmail.com>
 <CAB8mrRxp4GJMMbSTJ1FzUjg3=Y6ERYb-bMXzGqeOuB-XwwdCHQ@mail.gmail.com>
In-Reply-To: <CAB8mrRxp4GJMMbSTJ1FzUjg3=Y6ERYb-bMXzGqeOuB-XwwdCHQ@mail.gmail.com>
Date: Mon, 3 Jun 2024 22:42:32 +0200
Message-ID: <CAPyj-LA0U01TiCfnRGKkUzXhMqYvA745iYS__fDz=4MQZj3BHA@mail.gmail.com>
Subject: Re: [PHP-DEV] Fwd: Request for RFC Karma to Propose any_empty and
 all_empty Methods
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Elminson!

On Mon, May 27, 2024 at 6:51=E2=80=AFPM Elminson De Oleo Baez <edeoleo@gmai=
l.com> wrote:
>
> I hope this message finds you well. I am writing to request RFC karma for=
 my wiki account in order to propose a new RFC.
>
> My proposal involves the introduction of two new methods, any_empty and a=
ll_empty, for working with arrays. These methods are designed to provide bo=
olean outputs indicating whether any of the elements in an array are empty,=
 or if all elements are empty, respectively. I believe these methods will b=
e valuable additions to PHP=E2=80=99s array manipulation functionalities.
>
> Below is a brief overview of the proposed methods:
>
> any_empty(array $array): bool - This method will return true if any eleme=
nt in the provided array is empty, and false otherwise.
> all_empty(array $array): bool - This method will return true if all eleme=
nts in the provided array are empty, and false otherwise.
> These methods aim to simplify common array checks and improve code readab=
ility and efficiency.
>
> I look forward to your approval and any guidance you can provide on movin=
g forward with this proposal.

I'm skeptical personally about these functions. empty() doesn't have
the best semantics, and it's going to be rare that all your input
types exactly follow these semantics. I think a deeper dive into
common validation requirements might be good, to see whether they can
be abstracted in some way. It's also worth noting that validation
entails much more than just yielding true or false, e.g. coercion or
graceful errors.

Anyway, I granted you RFC karma. Good luck!

Ilija