Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125253
Date: Mon, 26 Aug 2024 02:26:00 -0400
To: Mike Schinkel <mike@newclarity.net>
Cc: "=?utf-8?Q?internals=40lists.php.net?=" <internals@lists.php.net>, 
 =?utf-8?Q?Rowan_Tommins_=5BIMSoP=5D?= <imsop.php@rwec.co.uk>, Larry
 Garfield <larry@garfieldtech.com>, John Bafford <jbafford@zort.net>
Message-ID: <0B974990-05FE-4C46-9C2B-3C243C7E8E81@getmailspring.com>
In-Reply-To: <99846F78-38F8-4549-B0A6-6310933AA78D@newclarity.net>
References: <99846F78-38F8-4549-B0A6-6310933AA78D@newclarity.net>
Subject: Re: [PHP-DEV] [RFC] Default expression
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="66cc1ff8_238e1f29_11f93"
From: john@coggeshall.org (John Coggeshall)

--66cc1ff8_238e1f29_11f93
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

(TL;DR; Down the thread a bit I put together a concrete example of why I'=
m opposed to this R=46C)

On Aug 26 2024, at 12:44 am, Mike Schinkel <mike=40newclarity.net> wrote:=

> Speaking only to =231 for the moment, there are many different places i=
n PHP where certain expressions make no sense either, yet I do not see th=
ose objecting calling the question for those other scenarios, and I ask m=
yself =22Why not=3F=22
>
> One obvious answer is =22because those are status quo and this is not=22=
 but I also maybe because the many non-sensical things that can be done e=
lsewhere are, in practice, not a problem as nobody ever does them. And wh=
y not=3F Because...they are nonsensical. Given this the arguments against=
 feel to me to be rather bikesheddy. But I will come back to =231.

The proposal in the R=46C creates a new dependency and backward compatibi=
lity issue for API developers that currently does not exist. It is not ju=
st because it allows for non-sensical expressions, but that it allows per=
fectly sensical expressions that would create dependencies between librar=
ies that I don't think are a worthwhile tradeoff. See my code example bel=
ow.
> Moving on to =232 I respect the argument in theory. But as we are const=
antly told the R=46C author's burden is to prove the necessity, it seems =
only reasonable and fair to expect that =E2=80=94 when many people see th=
e utility of and support an R=46C =E2=80=94 that those who object to it s=
hould provide some concrete examples of how their concerns would manifest=
 problems rather than just say =22it might allow something bad.=22
Consider this metaphor -- If I have a object with private properties, PHP=
 doesn't allow me to reach into that object and extract those values with=
out a lot of work (e.g. Reflection) by design. Right now, there are lots =
of libraries out there defining default values and right now today they a=
re in the same sense =22private=22 to the function/method they are define=
d for. This PR would change the visibility of those default values, pulli=
ng them higher up into the call stack where IMO they don't belong -- esse=
ntially making them a brand new dependency API devs need to worry about.
> I have looked for but yet not seen any examples of how effectively publ=
ishing a default value could actually cause a significant problem =E2=80=94=
 and this is the important part =E2=80=94 in a real-world scenario and no=
t just a contrived one.
> Sure if I have =60foo(int =24index=3D1)=60, a developer calls with =60f=
oo(default*3)=60, and then the author of foo changes the signature to =60=
foo(int =24index=3D0)=60 that might cause problems, but what is a real wo=
rld scenario where a developer would actually do that, the author then ch=
ange it, and then is causes a non-trivial problem=3F

How is that not a real-world contrived scenario=3F That is the problem. I=
t's that some library developer decided to change the default value for t=
heir own purposes and now any code that was relying on that default value=
 has broken. I don't think anyone needs to go hunting around GitHub or so=
mething to prove that people change default values between library releas=
es, nor that this R=46C would introduce a new dependency between upstream=
 APIs and the code that uses them to manage. See below for a fairly reaso=
nable example I whipped up.
> 3. =22How likely are people to accidentally do that stupid thing=3F=22
Experience has shown us time and time again that people will use the feat=
ures that get implemented, and once they exist we are stuck with the cons=
equences. Developers who consume APIs are rarely worrying about the devel=
opers who wrote those APIs. This is making it not only very easy to do a =
stupid thing, it's making the fact people are doing a stupid thing the pr=
oblem of an entirely different project/developer who now has to deal with=
 the reality any time they touch a default value they have to worry about=
 the downstream impacts, being granted zero control to prevent it from ha=
ppening. It's also something that would be hard for downstream developers=
 to even realize was a problem...
Library dev: =22BC break, I changed this default value=22
Downstream dev: =22Okay.... so how do I fix this code someone else wrote =
2 years ago so I can upgrade=3F=22
Library dev: =22I dunno, depends on how you used default so you're on you=
r own. I guess you better grep and hope you catch them all=22

> But if you disallow =60default=21=3D5=60, then you (likely=3F) also dis=
allow =60default=21=3D5 =3F default : 0=60 and any other *sensical* expre=
ssion with that sub-expression. Do we really want to flesh out all the po=
tential nonsensical expressions for a given use-case and build a custom p=
arser for this one R=46C=3F
As I previously said, I don't think this would be addressed in the parser=
 -- I think it'd have to be a runtime check (if such a check were to exis=
t).
That aside, no I don't really want to flesh out all the potential express=
ions to build those rules into the engine. I believe if we are going to a=
llow expressions for default values as proposed we =5Fneed=5F to build th=
ose rules, but given the circumstances I think it's more likely the R=46C=
 needs to be reconsidered, updated to reflect feedback, or withdrawn.
> Let me propose this example and see if you still hold firm to your opti=
on that the following expression would not be valid and that it still wou=
ld not be a good idea for the language:
> class MyDependency =7B...=7D
> function doSomething(MyDependency =24dep=3D new MyDependency) =7B...=7D=

> doSomething((default)->WithLogger(new Logger));

Let's make that a little more complicated so you'll see the problem -- Co=
nsider this rather lengthy example building off the concept of your examp=
le:
<=3Fphp
enum LoggerType: string
=7B
case DB =3D 'db';
case =46ILE =3D 'file';
case CLOUD =3D 'cloud';

public function getLogger(): LoggerInterface
=7B
return match(=24this)
=7B
static::DB =3D> new DatabaseLogger(),
static::=46ILE =3D> new =46ileLogger(),
static::CLOUD =3D> new CloudLogger()
=7D;
=7D
=7D

interface LoggerInterface
=7B
public function log(string =24x);
=7D

// Assume DatabaseLogger, etc. exist and implement LoggerInterface
class A
=7B
protected =3FLoggerInterface =24log;

public function withLogger(LoggerInterface=7CLoggerType =24a =3D new Data=
baseLogger): static
=7B
if(=24a instanceof LoggerInterface)
=7B
=24this->log =3D =24a;
return =24this;
=7D

=24this->log =3D =24a->getLogger();
return =24this;
=7D
=7D

(new A)->withLogger((default)->log('B'));
This would be valid under this R=46C, right=3F But now as the author of c=
lass A I later want to change the default of my withLogger method. Instea=
d of just passing in new DatabaseLogger, I now want to change my API defa=
ult to just a LoggerType::DB enum for reasons (What the reasons aren't re=
levant).
Today I don't have to think too hard about that change from an API BC per=
spective because the consumer has either passed in a LoggerInterface or a=
 LoggerType -- or left it empty and used it's default value. I can just c=
hange the default to LoggerType::DB and be on my way. The downstream deve=
loper will never know or care that I did it because if they wanted to cal=
l log() they had to first create their own instance of LoggerInterface an=
d have a reference to that object in their local context like so:
=24logger =3D LoggerType::DB->getLogger();
(new A)->withLogger(=24logger);
=24logger->log('B');

With this R=46C, now I can't change this API call without introducing a B=
C break in my library because I have no idea at this point if some downst=
ream caller decided to use my default value directly or not.
You can argue if this is a good API design or not, but it was only writte=
n to provide a real example of how pulling the default value higher up th=
e call chain and allowing it to be used in expressions is problematic for=
 library authors all to save a couple of lines of code on the consumer si=
de.
> > On Aug 25, 2024, at 12:23 PM, John Coggeshall <john=40coggeshall.org>=
 wrote:
> > I won't vote for this R=46C if the above code is valid, =46WIW. Unlik=
e include , default is a special-case with a very specific purpose -- one=
 that is reaching into someone else's API in a way the developer of that =
library doesn't explicitly permit.

> Ok, so if a developer of the API currently wants to indicate that other=
 developers CAN explicitly reach in then how would they do that, currentl=
y=3F
I'm honestly not sure what you're asking here. PHP currently doesn't allo=
w you access to the =22default value=22 of a function you are calling (ma=
ybe Reflection=3F I don't know offhand).
> Your argument seems to be it should implicitly be disallowed, but I do =
not see any way in which you are proposing a developer could explicitly e=
mpower a developer to allow it. At least not without a ton of boilerplate=
 which, for each default value, turns into a lot of extra code to create =
and then maintain.
> It seems one-sided to argue against allowing something that =22has not =
been explicitly allowed=22 if there is no way to explicitly allow it. And=
 I get you may say =22well that's not my job=22 to which =E2=80=94if you =
did =E2=80=94 I would ask =22Do you really only want to be the one who br=
ings the problem but not the solution=3F=22

Right now there isn't a problem. There is nothing lacking in the current =
language that prevents me from providing my own LoggerInterface or Logger=
Type to the withLogger above. This is a suggestion to expand the syntax o=
f the language to simplify something, not enable it to exist where before=
 it didn't. The R=46C would introduce something that makes it marginally =
easier for a downstream consumer of the API, at the cost of making life p=
ainful for library authors and worse not providing any way to prevent it =
from happening. So yes, I am pointing out a problem but not providing a s=
olution because I don't currently agree a solution is even needed.
Not all ideas make the cut the first time, and that's okay. Those of us w=
ho have stood up against this idea in its current form have tried to offe=
r our best thoughts as to how you might make it work by outlining that we=
 think there need to be rules around the types of expressions that would =
be allowed... these opinions don't come out of nowhere or meant to be obs=
tructionist -- still, they have largely been dismissed with strawman coun=
ters about how include statements let you do silly things, or responses l=
ike =22The truth always lies in the code, which is why R=46C authors are =
strongly encouraged to pursue patches where there is doubt, and similarly=
, I think counter-proposals on the mailing list should follow suit, other=
wise we can find ourselves arguing over nothing.=22 -- I don't agree with=
 that, or feel obligated to attempt to write patches for an idea I don't =
think is necessary in the first place.
John
--66cc1ff8_238e1f29_11f93
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>(TL;DR; Down the thread a bit I put together a concrete example of w=
hy I'm opposed to this R=46C)</div><br><div class=3D=22gmail=5Fquote=5Fat=
tribution=22>On Aug 26 2024, at 12:44 am, Mike Schinkel &lt;mike=40newcla=
rity.net&gt; wrote:</div><blockquote><div><div>Speaking only to =231 for =
the moment, there are many different places in PHP where certain expressi=
ons make no sense either, yet I do not see those objecting calling the qu=
estion for those other scenarios, and I ask myself =22Why not=3F=22</div>=
<br><div>One obvious answer is =22because those are status quo and this i=
s not=22 but I also maybe because the many non-sensical things that can b=
e done elsewhere are, in practice, not a problem as nobody ever does them=
. And why not=3F Because...they are nonsensical. Given this the arguments=
 against feel to me to be rather bikesheddy. But I will come back to =231=
.</div><br></div></blockquote><div><br><div>The proposal in the R=46C cre=
ates a new dependency and backward compatibility issue for API developers=
 that currently does not exist. It is not just because it allows for non-=
sensical expressions, but that it allows perfectly sensical expressions t=
hat would create dependencies between libraries that I don't think are a =
worthwhile tradeoff. See my code example below.</div><br><blockquote>Movi=
ng on to =232 I respect the argument in theory. But as we are constantly =
told the R=46C author's burden is to prove the necessity, it seems only r=
easonable and fair to expect that =E2=80=94 when many people see the util=
ity of and support an R=46C =E2=80=94 that those who object to it should =
provide some concrete examples of how their concerns would manifest probl=
ems rather than just say =22it might allow something bad.=22</blockquote>=
<br><div>Consider this metaphor -- If I have a object with private proper=
ties, PHP doesn't allow me to reach into that object and extract those va=
lues without a lot of work (e.g. Reflection) by design. Right now, there =
are lots of libraries out there defining default values and right now tod=
ay they are in the same sense =22private=22 to the function/method they a=
re defined for. This PR would change the visibility of those default valu=
es, pulling them higher up into the call stack where IMO they don't belon=
g -- essentially making them a brand new dependency API devs need to worr=
y about.</div><br><blockquote>I have looked for but yet not seen any exam=
ples of how effectively publishing a default value could actually cause a=
 significant problem =E2=80=94 and this is the important part =E2=80=94 i=
n a real-world scenario and not just a contrived one.</blockquote><blockq=
uote></blockquote><blockquote>Sure if I have =60foo(int =24index=3D1)=60,=
 a developer calls with =60foo(default*3)=60, and then the author of foo =
changes the signature to =60foo(int =24index=3D0)=60 that might cause pro=
blems, but what is a real world scenario where a developer would actually=
 do that, the author then change it, and then is causes a non-trivial pro=
blem=3F</blockquote><br><div>How is that not a real-world contrived scena=
rio=3F That <em>is</em>&nbsp; the problem. It's that some library develop=
er decided to change the default value for their own purposes and now any=
 code that was relying on that default value has broken. I don't think an=
yone needs to go hunting around GitHub or something to prove that people =
change default values between library releases, nor that this R=46C would=
 introduce a new dependency between upstream APIs and the code that uses =
them to manage. See below for a fairly reasonable example I whipped up.</=
div><br><blockquote>3. =22How likely are people to accidentally do that s=
tupid thing=3F=22</blockquote><br><div>Experience has shown us time and t=
ime again that people will use the features that get implemented, and onc=
e they exist we are stuck with the consequences. Developers who consume A=
PIs are rarely worrying about the developers who wrote those APIs. This i=
s making it not only very easy to do a stupid thing, it's making the fact=
 people are doing a stupid thing the problem of an entirely different pro=
ject/developer who now has to deal with the reality any time they touch a=
 default value they have to worry about the downstream impacts, being gra=
nted <em>zero</em>&nbsp; control to prevent it from happening. It's also =
something that would be hard for downstream developers to even realize wa=
s a problem... </div><br><div>Library dev: =22BC break, I changed this de=
fault value=22</div><div>Downstream dev: =22Okay.... so how do I fix this=
 code someone else wrote 2 years ago so I can upgrade=3F=22</div><div>Lib=
rary dev: =22I dunno, depends on how you used <code>default</code>&nbsp; =
so you're on your own. I guess you better grep and hope you catch them al=
l=22</div><br><blockquote>But if you disallow =60default=21=3D5=60, then =
you (likely=3F) also disallow =60default=21=3D5 =3F default : 0=60 and an=
y other *sensical* expression with that sub-expression. Do we really want=
 to flesh out all the potential nonsensical expressions for a given use-c=
ase and build a custom parser for this one R=46C=3F</blockquote><br><div>=
As I previously said, I don't think this would be addressed in the parser=
 -- I think it'd have to be a runtime check (if such a check were to exis=
t).</div><br><div>That aside, no I don't really want to flesh out all the=
 potential expressions to build those rules into the engine. I believe if=
 we are going to allow expressions for default values as proposed we =5Fn=
eed=5F to build those rules, but given the circumstances I think it's mor=
e likely the R=46C needs to be reconsidered, updated to reflect feedback,=
 or withdrawn.</div><br><blockquote>Let me propose this example and see i=
f you still hold firm to your option that the following expression would =
not be valid and that it still would not be a good idea for the language:=
</blockquote><blockquote></blockquote><blockquote>class MyDependency =7B.=
..=7D</blockquote><blockquote>function doSomething(MyDependency =24dep=3D=
 new MyDependency) =7B...=7D</blockquote><blockquote>doSomething((default=
)-&gt;WithLogger(new Logger));</blockquote><br><div>Let's make that a lit=
tle more complicated so you'll see the problem -- Consider this rather le=
ngthy example building off the concept of your example:</div><br><div>&lt=
;=3Fphp</div><br><div>enum LoggerType: string</div><div>=7B</div><div>&nb=
sp;&nbsp;&nbsp; case DB =3D 'db';</div><div>&nbsp;&nbsp;&nbsp; case =46IL=
E =3D 'file';</div><div>&nbsp;&nbsp;&nbsp; case CLOUD =3D 'cloud';</div><=
br><div>&nbsp;&nbsp;&nbsp; public function getLogger(): LoggerInterface</=
div><div>&nbsp;&nbsp;&nbsp; =7B</div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; return match(=24this)</div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =7B</div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; static::DB =3D&gt; new DatabaseLogger(),</div><div>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; static=
::=46ILE =3D&gt; new =46ileLogger(),</div><div>&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; static::CLOUD =3D&gt; new CloudL=
ogger() </div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =7D;</div><=
div>&nbsp;&nbsp;&nbsp; =7D</div><div>=7D</div><br><div>interface LoggerIn=
terface</div><div>=7B</div><div>&nbsp;&nbsp;&nbsp; public function log(st=
ring =24x);</div><div>=7D</div><br><div>// Assume DatabaseLogger, etc. ex=
ist and implement <code>LoggerInterface</code>&nbsp;</div><br><div>class =
A</div><div>=7B</div><div>&nbsp;&nbsp;&nbsp; protected =3FLoggerInterface=
 =24log;</div><br><div>&nbsp;&nbsp;&nbsp; public function withLogger(Logg=
erInterface=7CLoggerType =24a =3D new DatabaseLogger): static</div><div>&=
nbsp;&nbsp;&nbsp; =7B</div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; if(=24a instanceof LoggerInterface)</div><div>&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; =7B</div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; =24this-&gt;log =3D =24a;</div><div>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return =24this;</=
div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =7D</div><br><div>&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =24this-&gt;log =3D =24a-&gt;getL=
ogger();</div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return =24t=
his;</div><div>&nbsp;&nbsp;&nbsp; =7D</div><div>=7D</div><br><div>(new A)=
-&gt;withLogger((default)-&gt;log('B'));</div><br><div>This would be vali=
d under this R=46C, right=3F But now as the author of class A I later wan=
t to change the default of my <code>withLogger</code>&nbsp; method. Inste=
ad of just passing in <code>new DatabaseLogger,</code>&nbsp;I now want to=
 change my API default to just a <code>LoggerType::DB</code>&nbsp;enum fo=
r reasons (What the reasons aren't relevant). </div><br><div>Today I don'=
t have to think too hard about that change from an API BC perspective bec=
ause the consumer has either passed in a <code>LoggerInterface</code>&nbs=
p; or a <code>LoggerType</code>&nbsp; -- or left it empty and used it's d=
efault value. I can just change the default to <code>LoggerType::DB</code=
>&nbsp; and be on my way. The downstream developer will never know or car=
e that I did it because if they wanted to call <code>log()</code>&nbsp; t=
hey had to first create their own instance of <code>LoggerInterface</code=
>&nbsp; and have a reference to that object in their local context like s=
o:</div><br><div>=24logger =3D LoggerType:<span data-emoji-typing=3D=22tr=
ue=22>:DB-&gt;getLog</span>ger();</div><div>(new A)-&gt;withLogger(=24log=
ger);</div><div>=24logger-&gt;log('B');</div><br><div>With this R=46C, no=
w I <em>can't</em>&nbsp; change this API call without introducing a BC br=
eak in my library because I have no idea at this point if some downstream=
 caller decided to use my default value directly or not. </div><br><div>Y=
ou can argue if this is a good API design or not, but it was only written=
 to provide a real example of how pulling the default value higher up the=
 call chain and allowing it to be used in expressions is problematic for =
library authors all to save a couple of lines of code on the consumer sid=
e. </div><br><blockquote>&gt; On Aug 25, 2024, at 12:23 PM, John Coggesha=
ll &lt;john=40coggeshall.org&gt; wrote:</blockquote><blockquote>&gt; I wo=
n't vote for this R=46C if the above code is valid, =46WIW. Unlike includ=
e , default is a special-case with a very specific purpose -- one that is=
 reaching into someone else's API in a way the developer of that library =
doesn't explicitly permit.</blockquote><br><blockquote>Ok, so if a develo=
per of the API currently wants to indicate that other developers CAN expl=
icitly reach in then how would they do that, currently=3F</blockquote><br=
><div>I'm honestly not sure what you're asking here. PHP currently doesn'=
t allow you access to the =22default value=22 of a function you are calli=
ng (maybe Reflection=3F I don't know offhand).</div><br><blockquote>Your =
argument seems to be it should implicitly be disallowed, but I do not see=
 any way in which you are proposing a developer could explicitly empower =
a developer to allow it. At least not without a ton of boilerplate which,=
 for each default value, turns into a lot of extra code to create and the=
n maintain.</blockquote><blockquote></blockquote><blockquote>It seems one=
-sided to argue against allowing something that =22has not been explicitl=
y allowed=22 if there is no way to explicitly allow it. And I get you may=
 say =22well that's not my job=22 to which =E2=80=94if you did =E2=80=94 =
I would ask =22Do you really only want to be the one who brings the probl=
em but not the solution=3F=22</blockquote><br><div>Right now there isn't =
a problem. There is nothing lacking in the current language that prevents=
 me from providing my own <code>LoggerInterface</code>&nbsp; or <code>Log=
gerType</code>&nbsp; to the <code>withLogger</code>&nbsp; above. This is =
a suggestion to expand the syntax of the language to simplify something, =
not enable it to exist where before it didn't. The R=46C would introduce =
something that makes it marginally easier for a downstream consumer of th=
e API, at the cost of making life painful for library authors and worse n=
ot providing any way to prevent it from happening.&nbsp; So yes, I am poi=
nting out a problem but not providing a solution because I don't currentl=
y agree a solution is even needed. </div><br><div>Not all ideas make the =
cut the first time, and that's okay. Those of us who have stood up agains=
t this idea in its current form have tried to offer our best thoughts as =
to how you might make it work by outlining that we think there need to be=
 rules around the types of expressions that would be allowed... these opi=
nions don't come out of nowhere or meant to be obstructionist -- still, t=
hey have largely been dismissed with strawman counters about how <code>in=
clude</code>&nbsp; statements let you do silly things, or responses like =
=22The truth always lies in the code, which is why R=46C authors are stro=
ngly encouraged to pursue patches where there is doubt, and similarly, I =
think counter-proposals on the mailing list should follow suit, otherwise=
 we can find ourselves arguing over nothing.=22 -- I don't agree with tha=
t, or feel obligated to attempt to write patches for an idea I don't thin=
k is necessary in the first place. </div><br><div>John</div></div>
--66cc1ff8_238e1f29_11f93--