On Sun, Aug 25, 2024, at 10:29 AM, Bilge wrote:
> 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.
See, I approach it from an entirely different philosophical perspective:
To the extent possible, the language and compiler should prevent you from doing stupid things, or at
least make doing stupid things harder.
This is the design philosophy behind, well, most good user interfaces. It's why it's good
that US and EU power outlets are different, because they run different voltages, and blindly
plugging one into the other can cause damage or death.
This is the design philosophy behind all type systems: Make illogical or dangerous or "we know
it can't work" code paths a compile error, or even impossible to express at all.
This is the design philosophy behind password_hash() and friends: The easy behavior is, 99% of the
time, the right one, so doing the "right thing" is easy. Doing something dumb (like
explicitly setting password_hash() to use md5 or something) may be possible, but it requires extra
work to be dumb.
Good design makes the easy path the safe path.
Now, certainly, the definition of "stupid things" is subjective and squishy, and
reasonable people can disagree on where that threshold is. That's what a robust discussion is
for, to figure out what qualifies as a "stupid thing" in this case.
Rob has shown some possible, hypothetical uses for some of the seemingly silly possible
combinations, which may or may not carry weight with people. But there are others that are still
unjustified, so for now, I would still put "default != 5" into the "stupid
things" category, for example.
As you've noted, this is already applicable only in some edge cases to begin with, so enabling
edge cases of edge cases that only maybe make sense if you squint is very likely in the "stupid
things" territory.
> 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.
From one RFC author to another, it's better to make that list explicitly and let us
collectively think through the logic of it than to be light on details and not realize what will
break until later. We've had RFCs that did that, and it caused problems. The discussion can
absolutely be frustrating (boy do I know), but the language is better for it. So I'm glad you
did call it out so we could have this discussion.
--Larry Garfield