Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121673
MIME-Version: 1.0
References: <CAB-BujYUueXGAi+Mz1xjmy_AWGJy2VLzf6_rk3_O1tqaEbQ92w@mail.gmail.com>
 <CA+p1FaYk4_M+cczv8yRvefyfNhpPfcYMrQGc1x+S1Ai7-x_j=g@mail.gmail.com>
 <CAB-Bujb8g+g7OL34hBy+6LtLDiH9aXdrkZo7KdnAxhMs1FNjsA@mail.gmail.com>
 <CAB-BujaOckOXFBrWF2DbBmwSEcp2Y-9vZu_c=uxnDQc5=Va0eA@mail.gmail.com>
 <CA+p1FabQXDf-KV22Um=FoM6aQA=e7+i3kuAUaYf5bgJDU05+sQ@mail.gmail.com>
 <CAPzBOBNL0geVsFXJOPEA52_cjYEqiRSNdUB3V_Dm2oxc473U4A@mail.gmail.com> <CAB-BujZDcLcPKyoKZqyUSS1iu2NBwYVfp2X9tyhPksTKg91vNQ@mail.gmail.com>
In-Reply-To: <CAB-BujZDcLcPKyoKZqyUSS1iu2NBwYVfp2X9tyhPksTKg91vNQ@mail.gmail.com>
Date: Tue, 14 Nov 2023 18:49:12 +0100
Message-ID: <CAPzBOBMOZLKEvT4Jv9LiRi8V6M0_UszZpuA5s0DULY61B4_Qgg@mail.gmail.com>
To: Andreas Hennings <andreas@dqxtech.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Array functions with strict comparison
From: landers.robert@gmail.com (Robert Landers)

On Tue, Nov 14, 2023 at 1:39=E2=80=AFPM Andreas Hennings <andreas@dqxtech.n=
et> wrote:
>
> Hello Robert,
>
> On Tue, 14 Nov 2023 at 11:09, Robert Landers <landers.robert@gmail.com> w=
rote:
> >
> > Andreas,
> >
> > Just out of curiosity, what is the use case for this? I can't really
> > think of a practical case where strict checking is needed for these
> > functions. Usually, you have a really good idea of what is in the
> > arrays when writing the code and can handle any edge cases (like
> > nulls, empty strings, etc) long before you reach for these functions.
>
> I could ask the reverse question: When do you ever need a non-strict comp=
arison?
> I think in most modern php development, you would prefer the strict
> comparison version simply because it is more simple and predictable.
>
> But for real examples.
> One thing I remember is array_diff($arr, [null]) to remove NULL
> values, without removing empty strings.
> Perhaps we could say this is a special case that could be solved in
> other ways, because we only remove one value.
>
> Another thing is when writing reusable general-purpose functions that
> should work for all arrays.
> The caller might know the types of the array values, but the developer
> of the reusable function does not.
>
> Another problem is if your arrays contain anything that is not
> stringable. like objects and arrays.
>
> Maybe I will remember other examples that are more practical.
>
> Btw, as a general note on strict vs non-strict:
> In some cases you want a "half strict" comparison, where '5' equals 5,
> but true does NOT equal '1'.
> But for now I am happy to focus on pure strict comparison.
>
> Andreas
>
>
> >
> > Robert Landers
> > Software Engineer
> > Utrecht NL
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >

Hello Andreas,

> Another problem is if your arrays contain anything that is not
> stringable. like objects and arrays.

array_udiff() comes to mind here, is there a reason that doesn't work?
It would allow you to 'half-equals' things as well, if you want.

> I could ask the reverse question: When do you ever need a non-strict comp=
arison?

You actually answer your own question :)

> where '5' equals 5,

One of the most beautiful things about PHP is that null =3D=3D 0 =3D=3D fal=
se,
or '5' =3D=3D 5 =3D=3D 5.0, or 1 =3D=3D true =3D=3D 'hello world', which is=
 so
incredibly handy in web-dev that to ignore it is inviting bugs.
Headers may or may not be set, form values may or may not be set, JSON
documents may or may not be missing keys/values, etc. How everything
is coerced is extremely well documented and very obvious after working
with PHP for a while.

I'm reminded of this principle in PHP, quite often:

> Be conservative in what you do, be liberal in what you accept from others=
.

Robert Landers
Software Engineer
Utrecht NL