Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125217
Content-Type: multipart/alternative;
 boundary="------------2wPv3bob9k9LCHdNUo0CemYZ"
Message-ID: <3e0d031e-256f-47cd-9a2b-dcdc760f5498@scriptfusion.com>
Date: Sun, 25 Aug 2024 16:29:07 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Default expression
To: internals@lists.php.net
References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com>
 <0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com>
Content-Language: en-GB
In-Reply-To: <0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com>
From: bilge@scriptfusion.com (Bilge)

This is a multi-part message in MIME format.
--------------2wPv3bob9k9LCHdNUo0CemYZ
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.

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. Why does that matter? Because PHP already allows 
you to do many more ridiculous things, they're just not routinely 
presented to you so they're not part of your mind map. The end-user 
documentation will also not mention the nonsense cases, so the average 
developer will not think of them. You can write, `include(1 + 1);`, 
because `include()` accepts an expression. You will get: "Failed opening 
'2' for inclusion". Should we restrict that? No, because that's just how 
expressions work in any context where they're allowed. Special-casing 
the T_DEFAULT grammar would not only bloat the grammar rules but also 
increase the chance that new expression grammars introduced in future, 
which could conveniently interoperate with `default`, would be 
unintentionally excluded by omission.

Cheers,
Bilge

--------------2wPv3bob9k9LCHdNUo0CemYZ
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 25/08/2024 14:35, Larry Garfield
      wrote:<span style="white-space: pre-wrap">
</span></div>
    <blockquote type="cite"
      cite="mid:0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com"><span
      style="white-space: pre-wrap"></span><span
      style="white-space: pre-wrap">
</span>
      <pre class="moz-quote-pre" wrap="">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?</pre>
    </blockquote>
    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.<span style="white-space: pre-wrap">
</span><span style="white-space: pre-wrap">
</span>
    <blockquote type="cite"
      cite="mid:0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com">
      <pre class="moz-quote-pre" wrap="">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.</pre>
    </blockquote>
    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.<span style="white-space: pre-wrap"> I rarely use `goto` but that doesn't mean we shouldn't have the feature.
</span><span style="white-space: pre-wrap">
</span>
    <blockquote type="cite"
      cite="mid:0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com">
      <pre class="moz-quote-pre" wrap="">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 &gt; 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.
</pre>
    </blockquote>
    <p>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</p>
    <p>&gt;I'm reasonably certain you can write nonsensical PHP without
      this feature. I don't think we should be the nanny of developers.</p>
    <p>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 <i>expression</i>
      means where perhaps this criticism would not have been levied at
      all had I chosen not to do so. Why does that matter? Because PHP
      already allows you to do many more ridiculous things, they're just
      not routinely presented to you so they're not part of your mind
      map. The end-user documentation will also not mention the nonsense
      cases, so the average developer will not think of them. You can
      write, `include(1 + 1);`, because `include()` accepts an
      expression. You will get: "Failed opening '2' for inclusion".
      Should we restrict that? No, because that's just how expressions
      work in any context where they're allowed. Special-casing the
      T_DEFAULT grammar would not only bloat the grammar rules but also
      increase the chance that new expression grammars introduced in
      future, which could conveniently interoperate with `default`,
      would be unintentionally excluded by omission.</p>
    <p>Cheers,<br>
      Bilge<br>
    </p>
  </body>
</html>

--------------2wPv3bob9k9LCHdNUo0CemYZ--