Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125301
Date: Mon, 26 Aug 2024 23:37:23 -0400
To: Bilge <bilge@scriptfusion.com>
Cc: "=?utf-8?Q?internals=40lists.php.net?=" <internals@lists.php.net>
Message-ID: <D45F9BD5-5A44-45EA-8A9E-C9C899FB4EA4@getmailspring.com>
In-Reply-To: <d686f00c-ac41-460e-94fa-0a3041162f23@scriptfusion.com>
References: <d686f00c-ac41-460e-94fa-0a3041162f23@scriptfusion.com>
Subject: Re: [PHP-DEV] [RFC] Default expression
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="66cd49f3_74b0dc51_12a23"
From: john@coggeshall.org (John Coggeshall)

--66cd49f3_74b0dc51_12a23
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline



On Aug 26 2024, at 5:57 pm, Bilge <bilge@scriptfusion.com> wrote:
> In case it matters, my initial inclination was also to do what some others have suggested, and modify the SEND opcodes so that the default is not actually looked up using reflection at all, but rather we just send nothing to the function and it can use its default as it would normally, but since I had the good sense to ask an engine maintainer how they would approach this problem, they cautioned me that this was the approach Stas took 10 years ago (https://github.com/php/php-src/compare/master...smalyshev:php-src:skip_params7), that that approach was horrendous (paraphrasing) and they would never support something like that (mainly because there's like 11 of them and modifying them all would be a complete mess). So whilst you might find me quite unmoved by some of the arguments put forth on the mailing list and generally difficult to convince, it is not because I am stubborn in my naivete, it is because when wisdom was imparted, I listened. I am but a small man standing on the shou
lders of giants.
>
>

The RFC for Stas' implementation of default was very different not only in approach, but it was put forth at a different time to solve a different problem. I don't think it makes sense to conflate the two issues. Very importantly Stas was not proposing an expression syntax that increased visibility and access into function declaration defaults as you are proposing.
https://wiki.php.net/rfc/skipparams
> I am just about to amend the RFC with the major discussion points from detractors, however I am still missing a list of even one item that must absolutely be prohibited, along with an explanation as to why.
I've seen multiple explanations by many and I know I personally put a code example forth. I am not sure what prompts you to say that.
I'd be very interested in hearing from you, as the RFC author, specifically about that code example -- and why you believe the issue I described is worth the cost.
> Indeed, the entire point of the expression grammar is they can be composed freely with one another in any way you like; to do otherwise would be radical departure from the intended behaviour.
I think what has been lost in this conversation is that the "detractors" believe the intended behavior is not a good direction to take the language. It seems to me that we simply don't think default parameters should be directly accessible to the caller in a major percentage of the circumstances. Any discussion about expression restrictions or the like has only happened because those same detractors are offering potential compromise ideas. The fundamental problem with the RFC to me is that it's creating an access into function declarations that IMO is neither needed or wise.
Coogle

--66cd49f3_74b0dc51_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=
 5:57 pm, Bilge &lt;bilge=40scriptfusion.com&gt; wrote:</div><blockquote>=
<div class=3D=22moz-cite-prefix=22><div>In case it matters, my initial in=
clination was also to do what some others have suggested, and modify the =
SEND opcodes so that the default is not actually looked up using reflecti=
on at all, but rather we just send nothing to the function and it can use=
 its default as it would normally, but since I had the good sense to ask =
an engine maintainer how they would approach this problem, they cautioned=
 me that this was <a href=3D=22https://github.com/php/php-src/compare/mas=
ter...smalyshev:php-src:skip=5Fparams7=22 title=3D=22https://github.com/p=
hp/php-src/compare/master...smalyshev:php-src:skip=5Fparams7=22>the appro=
ach Stas took 10 years ago</a>, that that approach was horrendous (paraph=
rasing) and they would never support something like that (mainly because =
there's like 11 of them and modifying them all would be a complete mess).=
 So whilst you might find me quite unmoved by some of the arguments put f=
orth on the mailing list and generally difficult to convince, it is not b=
ecause I am stubborn in my naivete, it is because when wisdom was imparte=
d, I listened. I am but a small man standing on the shoulders of giants.<=
/div></div><br></blockquote><br><div>The R=46C for Stas' implementation o=
f <code>default</code>&nbsp; was very different not only in approach, but=
 it was put forth at a different time to solve a different problem. I don=
't think it makes sense to conflate the two issues. Very importantly Stas=
 was not proposing an expression syntax that increased visibility and acc=
ess into function declaration defaults as you are proposing.</div><br><di=
v><a href=3D=22https://wiki.php.net/rfc/skipparams=22 title=3D=22https://=
wiki.php.net/rfc/skipparams=22>https://wiki.php.net/rfc/skipparams</a><br=
></div><blockquote>I am just about to amend the R=46C with the major disc=
ussion points from detractors, however I am still missing a list of even =
one item that must absolutely be prohibited, along with an explanation as=
 to why.</blockquote><br><div>I've seen multiple explanations by many and=
 I know I personally put a code example forth. I am not sure what prompts=
 you to say that.</div><br><div>I'd be very interested in hearing from yo=
u, as the R=46C author, specifically about that code example -- and why y=
ou believe the issue I described is worth the cost.</div><br><blockquote>=
<font style=3D=22font-size:14.5px=22><font style=3D=22font-family:Nylas-P=
ro, Helvetica, &quot;Lucidia Grande&quot;, sans-serif=22>Indeed, the enti=
re point of the expression grammar is they can be composed freely with on=
e another in any way you like; to do otherwise would be radical departure=
 from the intended behaviour.</font></font></blockquote><br><div><font st=
yle=3D=22font-size:14.5px=22><font style=3D=22font-family:Nylas-Pro, Helv=
etica, &quot;Lucidia Grande&quot;, sans-serif=22>I think what has been lo=
st in this conversation is that the =22detractors=22 believe the intended=
 behavior is not a good direction to take the language. It seems to me th=
at we simply don't think default parameters should be directly accessible=
 to the caller in a major percentage of the circumstances. Any discussion=
 about expression restrictions or the like has only happened because thos=
e same detractors are offering potential compromise ideas. The fundamenta=
l problem with the R=46C to me is that it's creating an access into funct=
ion declarations that IMO is neither needed or wise.</font></font></div><=
br><div><font style=3D=22font-size:14.5px=22><font style=3D=22font-family=
:Nylas-Pro, Helvetica, &quot;Lucidia Grande&quot;, sans-serif=22>Coogle</=
font></font></div><br>
--66cd49f3_74b0dc51_12a23--