Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125292
Date: Mon, 26 Aug 2024 16:44:57 -0400
To: Matthew Weier O'Phinney <mweierophinney@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals
 <internals@lists.php.net>
Message-ID: <E1458589-B95C-43D0-A654-F8DB75782AB7@getmailspring.com>
In-Reply-To: <CAJp_myV3Riup2DyDWjgpHypDE6qP03Ogzdr6mZo6wWUmCtx16g@mail.gmail.com>
References: <CAJp_myV3Riup2DyDWjgpHypDE6qP03Ogzdr6mZo6wWUmCtx16g@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Default expression
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="66cce949_66334873_12a23"
From: john@coggeshall.org (John Coggeshall)

--66cce949_66334873_12a23
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline



On Aug 26 2024, at 2:11 pm, Matthew Weier O'Phinney <mweierophinney@gmail.com> wrote:
>
> I can see a few others:
>
> - string concatenation. I might want to prepend or append a string to a default.
>
> - fractional or multiplicative application, e.g. for durations/timeouts. These might require testing for non-zero first as well.

I have to be honest all of these both sound like really bad practices. Maybe I'm just not being imaginative enough... but if you don't control the upstream library why would you ever trust it like that? Writing a timeout default * 0.5 when default is 1000 is a really bad way to set your timeout to 500 -- because next time you done a composer update suddenly the upstream package set the timeout to 5000 and now instead of 500 your timeout has silently become 2500.
> - decorating a default instance (e.g. to lazily create a proxy without knowing the default implementation used for an argument hinted against an interface)
This is exactly the usage I'm highlighted as problematic in my code example. You're introducing a new worry for the upstream API developer that doesn't need to exist, and violating a separation principle that has existed in PHP since default parameters were created 25+ years ago.

> IF it's possible to accomplish, I think it's better to identify the "leaving this open will create WTF situations" than to prematurely lock _everything_ down up front.

If this feature is released with an overly broad scope in terms of expressions, etc. it's not like we can take it back at that point because now people are using it in unknown ways. It is not one I'm comfortable with a "let's move forward and see what happens" approach.
I don't think this RFC is anywhere near a state of being ready for a vote and I'd like to see it go back and be updated with all this feedback before we continue going back and forth on the mailing list about it. This isn't a small feature, despite the fact on the surface it seems relatively minor as compared to other things. It is introducing a whole new concept into PHP of, at least in some circumstances, suddenly making the default parameter in a function signature a formal part of it and of utmost importance that API developers have to think about changing. It's a big deal.
Offhand, I am unaware of what other languages have done this or allow anything like it (are there any?) -- and there have been demonstrated real concerns backed with code examples of how this becomes problematic. Not to mention the fact it would retroactively make all default parameters in all PHP code suddenly accessible by downstream consumers in a way the author simply never intended for. As others have mentioned, this is just as big of a deal as if there was an RFC that suddenly gave developers a syntax to access object's private methods by adding ! to the property name or something (e.g. an RFC that proposed accessing private members of an object just by doing $foo->myPrivate! ).
I am being left with the impression based on these emails that those in favor of this are hand-waving past some very legitimate concerns trying to push it through, rather than taking the appropriate action of accepting the feedback in the collaborative fashion it was intended and going back to the RFC to address those concerns fully. Perhaps that impression is mistaken, and if so I apologize... But to be clear I don't think there is anywhere near enough consensus on this RFC to make this a slam dunk, nor do I think it's a few tweaks away from being adoptable.

--66cce949_66334873_12a23
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><br><div class=3D=22gmail=5Fquote=5Fattribution=22>On Aug 26 2024, at=
 2:11 pm, Matthew Weier O'Phinney &lt;mweierophinney=40gmail.com&gt; wrot=
e:</div><blockquote><div><div><br></div><div>I can see a few others:</div=
><div><br></div><div>- string concatenation. I might want to prepend or a=
ppend a string to a default.&nbsp;</div><div><br></div><div>- fractional =
or multiplicative application, e.g. for durations/timeouts. These might r=
equire testing for non-zero first as well.</div></div></blockquote><div><=
br><div>I have to be honest all of these both sound like really bad pract=
ices. Maybe I'm just not being imaginative enough... but if you don't con=
trol the upstream library why would you ever trust it like that=3F Writin=
g a timeout <code>default * 0.5</code>&nbsp; when <code>default</code>&nb=
sp; is <code>1000 </code>&nbsp;is a really bad way to set your timeout to=
 <code>500</code>&nbsp; -- because next time you done a <code>composer up=
date</code>&nbsp; suddenly the upstream package set the timeout to <code>=
5000</code>&nbsp; and now instead of 500 your timeout has silently become=
 <code>2500.</code></div><br><blockquote>- decorating a default instance =
(e.g. to lazily create a proxy without knowing the default implementation=
 used for an argument hinted against an interface)</blockquote><br><div>T=
his is exactly the usage I'm highlighted as problematic in my code exampl=
e. You're introducing a new worry for the upstream API developer that doe=
sn't need to exist, and violating a separation principle that has existed=
 in PHP since default parameters were created 25+ years ago.</div><div><b=
r></div><blockquote>I=46 it's possible to accomplish, I think it's better=
 to identify the =22leaving this open will create WT=46 situations=22 tha=
n to prematurely lock =5Feverything=5F down up front.&nbsp;</blockquote><=
div><br><div>If this feature is released with an overly broad scope in te=
rms of expressions, etc. it's not like we can take it back at that point =
because now people are using it in unknown ways. It is not one I'm comfor=
table with a =22let's move forward and see what happens=22 approach.</div=
><br><div>I don't think this R=46C is anywhere near a state of being read=
y for a vote and I'd like to see it go back and be updated with all this =
feedback before we continue going back and forth on the mailing list abou=
t it. This isn't a small feature, despite the fact on the surface it seem=
s relatively minor as compared to other things. It is introducing a whole=
 new concept into PHP of, at least in some circumstances, suddenly making=
 the default parameter in a function signature a formal part of it and of=
 utmost importance that API developers have to think about changing. It's=
 a big deal.</div><br><div>Offhand, I am unaware of what other languages =
have done this or allow anything like it (are there any=3F) -- and there =
have been demonstrated real concerns backed with code examples of how thi=
s becomes problematic. Not to mention the fact it would retroactively mak=
e all default parameters in all PHP code suddenly accessible by downstrea=
m consumers in a way the author simply never intended for.&nbsp; As other=
s have mentioned, this is just as big of a deal as if there was an R=46C =
that suddenly gave developers a syntax to access object's private methods=
 by adding <code>=21</code>&nbsp; to the property name or something (e.g.=
 an R=46C that proposed accessing private members of an object just by do=
ing <code>=24foo-&gt;myPrivate=21</code>&nbsp;).</div><br><div>I&nbsp; am=
 being left with the impression based on these emails that those in favor=
 of this are hand-waving past some very legitimate concerns trying to pus=
h it through, rather than taking the appropriate action of accepting the =
feedback in the collaborative fashion it was intended and going back to t=
he R=46C to address those concerns fully. Perhaps that impression is mist=
aken, and if so I apologize... But to be clear I don't think there is any=
where near enough consensus on this R=46C to make this a slam dunk, nor d=
o I think it's a few tweaks away from being adoptable.</div><br></div></d=
iv>
--66cce949_66334873_12a23--