Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125238
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 25 Aug 2024 15:40:40 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <d0d2e433-8d6f-4351-b40d-57a5119654d5@app.fastmail.com>
In-Reply-To: <3e0d031e-256f-47cd-9a2b-dcdc760f5498@scriptfusion.com>
References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com>
 <0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com>
 <3e0d031e-256f-47cd-9a2b-dcdc760f5498@scriptfusion.com>
Subject: Re: [PHP-DEV] [RFC] Default expression
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Aug 25, 2024, at 10:29 AM, Bilge wrote:
> On 25/08/2024 14:35, Larry Garfield wrote:=20
>> 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 in=
to 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 t=
he approach we took, because the alternative would have been changing ho=
w values are sent to functions, which would have required a lot more cha=
nges to the engine with no clear benefit. Internally it literally calls =
the reflection API, but a low-level call, that elides the class instanti=
ation 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 s=
ituation where this is something I needed.  Some of the examples show va=
lid use cases (eg, the "default plus this binary flag" example), but aga=
in, I've never actually run into that myself in practice. That's fine. N=
ot 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 neede=
d, the frequency by which it is needed in no way diminishes its usefulne=
ss. I rarely use `goto` but that doesn't mean we shouldn't have the feat=
ure. My other concern is the list of supported expression types.  I unde=
rstand how the implementation would naturally make all of those syntacti=
cally valid, but it seems many of them, if not most, are semantically no=
nsensical.  Eg, `default > 1` would take a presumably numeric default va=
lue and output a boolean, which should really never be type compatible w=
ith the function being called.  (A param type of int|bool is a code smel=
l at best, and a fatal waiting to happen at worst.)  In practice, I thin=
k a majority of those expressions would be logically nonsensical, so I w=
onder if it would be better to only allow a few reasonable ones and bloc=
k the others, to keep people from thinking nonsensical code would do som=
ething useful.


> Since you're not the only one raising this, I will address it, but jus=
t=20
> to say there is no good reason, in my mind, to ever prohibit the=20
> expressiveness. To quote Rob
>
>>I'm reasonably certain you can write nonsensical PHP without this feat=
ure. 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 fro=
m 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 t=
hey 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 eve=
n impossible to express at all.

This is the design philosophy behind password_hash() and friends: The ea=
sy behavior is, 99% of the time, the right one, so doing the "right thin=
g" 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 squi=
shy, and reasonable people can disagree on where that threshold is.  Tha=
t'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 peo=
ple.  But there are others that are still unjustified, so for now, I wou=
ld still put "default !=3D 5" into the "stupid things" category, for exa=
mple.

As you've noted, this is already applicable only in some edge cases to b=
egin with, so enabling edge cases of edge cases that only maybe make sen=
se 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 wen=
t=20
> to the trouble of listing out every permutation of what *expression*=20
> means where perhaps this criticism would not have been levied at all=20
> had I chosen not to do so.=20

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