Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:131065
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Fri, 29 May 2026 12:13:14 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <1c8f3c94-42fe-439f-80b2-6c2273b22f55@app.fastmail.com>
In-Reply-To: 
 <CAEM3Mn2eJngj6EymLvbxFsF=3X-eq4VvWd7pdFeiOoOViSHCbQ@mail.gmail.com>
References: 
 <CAEM3Mn3pVE5cJZA0jEm_u63_47fPKfbStsrM=gWcrX30WQ-gSg@mail.gmail.com>
 <ae83e461-5ba4-4100-abd0-17ea82c42e9d@app.fastmail.com>
 <CAEM3Mn2eJngj6EymLvbxFsF=3X-eq4VvWd7pdFeiOoOViSHCbQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [Pre-RFC] Null coalescing associative array elements
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, May 29, 2026, at 11:58 AM, Alexander Egorov wrote:

> 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.

A data format that has a mix of required-even-if-null and optional fields is a broken data format.  We should not design language features around a broken data format.  (I realize that the broken data format is often provided by a 3rd party, not the PHP developer, so it's not the PHP developer's fault that the data format is broken.  But the point stands that we should not build around that.)

>> My second thought is that this is yet another reason why using associative arrays as if they were a data structure is wrong and should be avoided; just use a class and everything will be fine.  If you need to serialize it later, there's many serializers on the market if JsonSerialize isn't sufficient.
>
> 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 will
> 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.

Disclosure: I am the author of Crell/Serde, one of the aforementioned serialization libraries.  It's also super easy to just "drop into" a project and start using, even without wiring it into a container or anything.  And I wouldn't make use of this feature, as it doesn't fit the way Serde works to begin with.

--Larry Garfield