Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:131064
Precedence: list
MIME-Version: 1.0
References: <CAEM3Mn3pVE5cJZA0jEm_u63_47fPKfbStsrM=gWcrX30WQ-gSg@mail.gmail.com>
 <ae83e461-5ba4-4100-abd0-17ea82c42e9d@app.fastmail.com>
In-Reply-To: <ae83e461-5ba4-4100-abd0-17ea82c42e9d@app.fastmail.com>
Date: Fri, 29 May 2026 19:58:09 +0300
Message-ID: <CAEM3Mn2eJngj6EymLvbxFsF=3X-eq4VvWd7pdFeiOoOViSHCbQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [Pre-RFC] Null coalescing associative array elements
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: amego2006@gmail.com (Alexander Egorov)

Thanks for the feedback!

=D0=BF=D1=82, 29 =D0=BC=D0=B0=D1=8F 2026 =D0=B3., 19:06 Larry Garfield <lar=
ry@garfieldtech.com>:
> My first thought is that the current code, which assigns potentially null=
 values, works fine if you throw an array_filter() at it at the end.
>
> $array =3D [
>     'field1' =3D> $param1,
>     'field2' =3D> $param2,
>     'field3' =3D> $param3_which_is_null,
> ];
>
> $a =3D array_filter($array);
> // $a now omits the null fields

array_filter will only cover the cases when you need to filter all
fields by the same criteria (null's in this case).
But it does not fit the case when you still have some mandatory fields
even if they are null, but some are optional.
At least in the simplest form, but otherwise in more complex forms
we'll still come up with additional code.

> My second thought is that this is yet another reason why using associativ=
e arrays as if they were a data structure is wrong and should be avoided; j=
ust use a class and everything will be fine.  If you need to serialize it l=
ater, there's many serializers on the market if JsonSerialize isn't suffici=
ent.

Wrong or not, using arrays as an intermediate for serializing is still
very common.
Also, it is a common case when developers have their in-house
serialization mechanisms.

But whatever serialization you use, the serialization library by itself wil=
l
still need to perform corresponding "if"'s or other logic to
conditionally include/exclude the fields.
So, such feature can prove useful for serialization libraries themselves.

Another thing is that we don't only work with production-ready code
which presumably already
has or should have a proper "infrastructure" for serialization. We can
still work with some draft
or MVP projects where we need to do things fast and simple first. And
such feature can prove handy.