On Mon, Jun 1, 2026 at 4:05 PM Alex Rock <[email protected]> wrote: > > 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.
I may have probably formulated my argument badly, but I didn't mean that "since PHP already allows us to do bad things, let's do it more comfortably". I meant that there is nothing bad in making such "variable" arrays in the first place. > 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. Whatever instrument or feature you give to the people, some will always find bad or inappropriate use for them, and you can't control it. Even if the feature by itself is supposed to be the "absolutely best practice in the world". I could give numerous examples when any good feature of the language is used in an unimaginable way, and PHP didn't promote that in any way. The fact that we now have rail-guided circular saws does not mean at all that hand-driven jigsaws are deprecated. They are still thoroughly used and still have their own applications, and switching to the rail-guided saw may not even be possible, because these are two different instruments, each for its own "domain". What you're essentially saying is that people are supposed to only "cut big panels" with PHP, and not do some other kinds of things, and thus people should necessarily switch to circular saws. Which is obviously not the case, because lots of people do other kinds of "woodworking" for which "hand-driven jigsaw" in the context of PHP is still preferable. > 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. Exactly. That's what I was talking about above. The fact that some people would find a bad use of some instrument or feature does not mean that this instrument or feature is bad by itself. When you and Larry are talking about "bad practices", as I see it, you're mostly talking about some specific applications of arrays, and what you're concerned about is that in these specific applications "free-form" arrays would be bad. But as I've said, arrays as a language feature are decoupled from that, from exact usages, and there is nothing bad in manipulating them the way you like it. It's like string concatenation. Is it bad by itself? Obviously not. But in some specific applications it can be considered a bad practice. > 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. Again, arrays are not about broken data formats. Arrays are a technical instrument for whatever purposes. They are not just outdated "ancestors" of strict classes or any other fixed data structures. As it seems to me, both you and Larry miss that associative arrays are also (or probably first and foremost) key-value dictionaries. And the fact that some people use them badly to describe some specific objects does not make arrays bad. But using them as key-value dictionaries with a variable set of keys is an absolutely valid application of them. And that's why it is good to have possibilities to manipulate them. > After all, nothing prevents you from writing this: > > ``` > $someCondition && $array['field'] = $value; > ``` Some people, including myself, consider this exact thing as a bad practice. A logical expression floating in the air, the result of which is not used (neither assigned nor returned). Moreover, an expression for the sole purpose of implicit invocation of some logic. It's just a hack exploiting the way such logical expressions are evaluated. Meanwhile I'm aware that such a construct is frequently used even inside the most popular frameworks and libraries.
