Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125243
Content-Type: multipart/alternative;
 boundary="------------DcFbKzJew21gjcjbyQJi6ILX"
Message-ID: <928d6c8c-c969-4d55-82ff-5da8fc3d3035@scriptfusion.com>
Date: Sun, 25 Aug 2024 22:51:45 +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>
 <3e0d031e-256f-47cd-9a2b-dcdc760f5498@scriptfusion.com>
 <e2cd7203-8a25-494d-9c9d-b8abad02c8e8@rwec.co.uk>
 <6afeb23a-867f-457d-9b13-fdf5af02c31e@scriptfusion.com>
 <F374AE89-A6E4-4C40-9C33-6569D47589ED@rwec.co.uk>
Content-Language: en-GB
In-Reply-To: <F374AE89-A6E4-4C40-9C33-6569D47589ED@rwec.co.uk>
From: bilge@scriptfusion.com (Bilge)

This is a multi-part message in MIME format.
--------------DcFbKzJew21gjcjbyQJi6ILX
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 25/08/2024 22:09, Rowan Tommins [IMSoP] wrote:
>
> On 25 August 2024 21:00:03 BST, Bilge<bilge@scriptfusion.com>  wrote:
>> class Suspension {
>>      /**
>>       * @param int $delay Specifies the delay in milliseconds.
>>       */
>>      public function suspend(int $delay = 1_000) {
>>          var_dump($delay);
>>      }
>> }
>>
>> class MySuspension extends Suspension {
>>      /**
>>       * @param float|int|null $delay Specifies the delay in seconds.
>>       */
>>      public function suspend(float|int|null $delay = null) {
>>          parent::suspend((int)(($delay ?? 0) * 1000) ?: default);
>>      }
>> }
>>
>> new MySuspension()->suspend(2.2345); // int(2234)
>>
>> Not only have I demonstrated the need to use multiplication or division to change the scale, but also the need to cast.
> Possibly something got lost as you redrafted the example, because as you've written it, neither the multiplication nor the cast are applied to the value looked up by "default". The parameter reduces to "(expression) ?: default", which I've already agreed is useful.

Great! I'm glad we're finally getting to this, because I think this is 
what you, and everyone advocating for a restricted grammar, is actually 
missing. You think you've caught me in some kind of "gotcha" moment, but 
fair warning, I'm about to play my Uno Reverse card.

What you're saying is that, somehow, even though the default must be 
constrained to a restricted subset of permissible grammars, it is still 
acceptable to have unrestricted expressions in the other operands. So, 
in this example, somehow `expr ?: default` is OK.This is simply 
impossible and would cause catastrophic shift/reduce conflicts in the 
grammar. If `default` is to live in a restricted subset of allowed 
expression grammars, then it can only recurse with those same 
restrictions, meaning /both/ operands of any operators are so 
restricted. Ergo I do not need to demonstrate the usefulness of applying 
other operators /directly/ to `default`, merely including them 
/somewhere/ in the expression is sufficient to demonstrate they are 
useful because at that point we're back to recursing the general 
expression grammar (free of any restrictions), unless and until you're 
willing to concede those particular operators I've just demonstrated the 
useful application for should be entered into the arbitrarily-selected 
restricted subset of grammars allowed to apply to `default`.

If you believe I am incorrect about this, I encourage you to submit a 
(working) Bison patch to demonstrate how a restricted expression grammar 
subset can still recurse with the unrestricted superset, then we can 
start having this discussion more seriously.

Cheers, Bilge

--------------DcFbKzJew21gjcjbyQJi6ILX
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!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 22:09, Rowan Tommins
      [IMSoP] wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:F374AE89-A6E4-4C40-9C33-6569D47589ED@rwec.co.uk">
      <pre class="moz-quote-pre" wrap="">

On 25 August 2024 21:00:03 BST, Bilge <a class="moz-txt-link-rfc2396E" href="mailto:bilge@scriptfusion.com">&lt;bilge@scriptfusion.com&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">class Suspension {
    /**
     * @param int $delay Specifies the delay in milliseconds.
     */
    public function suspend(int $delay = 1_000) {
        var_dump($delay);
    }
}

class MySuspension extends Suspension {
    /**
     * @param float|int|null $delay Specifies the delay in seconds.
     */
    public function suspend(float|int|null $delay = null) {
        parent::suspend((int)(($delay ?? 0) * 1000) ?: default);
    }
}

new MySuspension()-&gt;suspend(2.2345); // int(2234)

Not only have I demonstrated the need to use multiplication or division to change the scale, but also the need to cast.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">Possibly something got lost as you redrafted the example, because as you've written it, neither the multiplication nor the cast are applied to the value looked up by "default". The parameter reduces to "(expression) ?: default", which I've already agreed is useful.</pre>
    </blockquote>
    <p>Great! I'm glad we're finally getting to this, because I think
      this is what you, and everyone advocating for a restricted
      grammar, is actually missing. You think you've caught me in some
      kind of "gotcha" moment, but fair warning, I'm about to play my
      Uno Reverse card.</p>
    <p>What you're saying is that, somehow, even though the default must
      be constrained to a restricted subset of permissible grammars, it
      is still acceptable to have unrestricted expressions in the other
      operands. So, in this example, somehow `expr ?: default` is OK.<span
      style="white-space: pre-wrap"> This is simply impossible and would cause catastrophic shift/reduce conflicts in the grammar. If `default` is to live in a restricted subset of allowed expression grammars, then it can only recurse with those same restrictions, meaning <i>both</i> operands of any operators are so restricted. Ergo I do not need to demonstrate the usefulness of applying other operators <i>directly</i> to `default`, merely including them <i>somewhere</i> in the expression is sufficient to demonstrate they are useful because at that point we're back to recursing the general expression grammar (free of any restrictions), unless and until you're willing to concede those particular operators I've just demonstrated the useful application for should be entered into the arbitrarily-selected restricted subset of grammars allowed to apply to `default`.
</span></p>
    <p><span style="white-space: pre-wrap">If you believe I am incorrect about this, I encourage you to submit a (working) Bison patch to demonstrate how a restricted expression grammar subset can still recurse with the unrestricted superset, then we can start having this discussion more seriously.</span></p>
    <p><span style="white-space: pre-wrap">Cheers,
Bilge
</span></p>
  </body>
</html>

--------------DcFbKzJew21gjcjbyQJi6ILX--