Le 29/05/2026 à 19:46, Alexander Egorov a écrit :
On Fri, May 29, 2026 at 8:14 PM Larry Garfield<[email protected]> wrote:
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.)
I generally agree with you about broken data formats, but I think it does not
really relate to the language feature itself. The reason and motivation why I'm
suggesting this feature is not to promote building around broken data formats,
but to have a convenient syntax for what is anyway being done more or
less often.
This argument doesn't hold. I've mostly been working on legacy PHP
projects for the past 18 years, and almost all of them benefited from
PHP's quirkness, sometimes in the ugliest possible way, especially when
it involved arrays.
I know that "in the past" we didn't have good handling of data
structures and validations, but nowadays, nobody should rely on older
problematic practices just because the language allows doing so.
If an app has broken formats, I think it's hugely counter-productive
that the PHP language itself evolves in favor of making broken formats
"more readable", because it doesn't at all encourage modernisation of
older codebases, or of bad practices whatever their age.
It is always developer's decision or necessity to do things this or that way,
and PHP anyway (as any other language) allows developers to have whatever
data-structures they want without obligation to do things "right", because
"right" is often very relative. The language is first and foremost an
instrument.
A woodworker willing to cut big panels could use a hand-driven jigsaw,
but these days we also have rail-guided circular saws. Just because some
people use jigsaws doesn't mean we should improve the whole setup around
jigsaws. They can keep it, of course, but more experienced people will
definitely remind them that cutting panels with a rail-guided circular
saw is faster, more precise, and less damage-prone.
Same here.
Just because we have arrays doesn't mean they should be recommended as a
safe data structure.
Specifically, associative arrays by themselves are completely
decoupled from what
exactly they are used for, and PHP anyway allows to dynamically add or
remove (unset)
keys from them. So, the feature I'm suggesting is about having a more convenient
tool for that, and not about building around bad data formats.
As said by Larry: the reasons you expose for your RFC are usually
considered not-so-good practices. Just because an array allows you to do
a lot of silly things doesn't mean you should do it.
And if the language evolves with a new favor for such not-so-good
practices, only a niche part of people will actually go against it.
For instance, I haven't even used property hooks because they often
imply having anemic stateful classes with getters and setters, and using
property hooks hides all the logic that one could have with rich
meaningful self-descriptive mutating methods. But I've seen people
overly use property hooks. Same as constructor property promotion: lots
of people use them for everything, sometimes mixing constructor-promoted
properties and class-declared properties, and it's so annoying to mix
both that I usually use constructor promotion only for DI.
Not all features are meant to be used "just to be used", neither to
please one or two people that want to ease a bad way of coding.
After all, nothing prevents you from writing this:
```
$someCondition && $array['field'] = $value;
```
Instead of your initial proposal:
```
if ($someCondition) {
$array['field'] = $value;
}
```
So why won't we code like this, while it would potentially help making a
one-liner out of it for all optional fields?
