On 25/08/2024 14:35, Larry Garfield wrote:
The approach here seems reasonable overall. The mental model I have from the RFC is
"yoink the default value out of the function, drop it into this expression embedded
in the function call, and let the chips fall where they may." Is that about
accurate?
Yes, as it happens. That is the approach we took, because the
alternative would have been changing how values are sent to functions,
which would have required a lot more changes to the engine with no clear
benefit. Internally it literally calls the reflection API, but a
low-level call, that elides the class instantiation and unnecessary
hoops of the public interface that would just slow it down.
My main holdup is the need. I... can't recall ever having a situation where this is
something I needed. Some of the examples show valid use cases (eg, the "default
plus this binary flag" example), but again, I've never actually run into that myself
in practice.
That's fine. Not everyone will have such a need, and of those that do,
I'm willing to bet it will be rare or uncommon at best. But for those
times it is needed, the frequency by which it is needed in no way
diminishes its usefulness.I rarely use `goto` but that doesn't mean we
shouldn't have the feature.
My other concern is the list of supported expression types. I understand how the
implementation would naturally make all of those syntactically valid, but it seems
many of them, if not most, are semantically nonsensical. Eg, `default > 1`
would take a presumably numeric default value and output a boolean, which should
really never be type compatible with the function being called. (A param type of
int|bool is a code smell at best, and a fatal waiting to happen at worst.) In
practice, I think a majority of those expressions would be logically nonsensical,
so I wonder if it would be better to only allow a few reasonable ones and block
the others, to keep people from thinking nonsensical code would do something
useful.
Since you're not the only one raising this, I will address it, but just
to say there is no good reason, in my mind, to ever prohibit the
expressiveness. To quote Rob
>I'm reasonably certain you can write nonsensical PHP without this
feature. I don't think we should be the nanny of developers.
I fully agree with that sentiment. It seems to be biting me that I went
to the trouble of listing out every permutation of what /expression/
means where perhaps this criticism would not have been levied at all had
I chosen not to do so. Why does that matter? Because PHP already allows
you to do many more ridiculous things, they're just not routinely
presented to you so they're not part of your mind map. The end-user
documentation will also not mention the nonsense cases, so the average
developer will not think of them. You can write, `include(1 + 1);`,
because `include()` accepts an expression. You will get: "Failed opening
'2' for inclusion". Should we restrict that? No, because that's just how
expressions work in any context where they're allowed. Special-casing
the T_DEFAULT grammar would not only bloat the grammar rules but also
increase the chance that new expression grammars introduced in future,
which could conveniently interoperate with `default`, would be
unintentionally excluded by omission.
Cheers,
Bilge
