Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121675
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> <CAPzBOBMOZLKEvT4Jv9LiRi8V6M0_UszZpuA5s0DULY61B4_Qgg@mail.gmail.com>
In-Reply-To: <CAPzBOBMOZLKEvT4Jv9LiRi8V6M0_UszZpuA5s0DULY61B4_Qgg@mail.gmail.com>
Date: Tue, 14 Nov 2023 20:06:26 +0100
Message-ID: <CAB-BujZo9qDhvaRcjb-B89vTgAByO7--tZT7C4Gkv7zL+4wPCg@mail.gmail.com>
To: Robert Landers <landers.robert@gmail.com>
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: andreas@dqxtech.net (Andreas Hennings)

On Tue, 14 Nov 2023 at 18:49, Robert Landers <landers.robert@gmail.com> wro=
te:
>
> On Tue, Nov 14, 2023 at 1:39=E2=80=AFPM Andreas Hennings <andreas@dqxtech=
.net> wrote:
> >
> > Hello Robert,
> >
> > On Tue, 14 Nov 2023 at 11:09, Robert Landers <landers.robert@gmail.com>=
 wrote:
> > >
> > > 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 co=
mparison?
> > 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.

Yes this would work, with a callback that does strict diff.
But this is going to be much slower than a native array_diff() for large ar=
rays.
Also, array_udiff() is weird in that it it expects a sorting
comparator function rather than a boolean comparator function.

>
> > I could ask the reverse question: When do you ever need a non-strict co=
mparison?
>
> 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 f=
alse,
> 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.

One problem of =3D=3D in php and in javascript is that it is not transitive=
.
And I would argue in most cases it does a lot more casting than we
need, in a way that can be perceived as surprising.

> 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 imagine a user study would come to a different conclusion than "very obvi=
ous".
But ok.

Anyway, time for an RFC.

(I was going to write more, but I should protect this list from my
preaching and arguing)

Andreas

>
> I'm reminded of this principle in PHP, quite often:
>
> > Be conservative in what you do, be liberal in what you accept from othe=
rs.
>
> Robert Landers
> Software Engineer
> Utrecht NL