Re: [Pre-RFC] Null coalescing associative array elements
| From: | Larry Garfield | Date: | Fri, 29 May 2026 17:13:14 +0000 |
| Subject: | Re: [Pre-RFC] Null coalescing associative array elements | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-131065@lists.php.net to get a copy of this message | ||
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