Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125227
Content-Type: multipart/alternative;
 boundary="------------wbt7nPAKhVRi7Q4B3TyjbfHT"
Message-ID: <04e02cb9-a2ea-457c-9f81-9d20ddb4d559@scriptfusion.com>
Date: Sun, 25 Aug 2024 18:30:56 +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>
 <CAPyj-LDLsHYcnAuka9OLdb3_YXd1_1yjvj+xvYuJYUKWpk61SQ@mail.gmail.com>
 <69a5258d-05e4-420e-b4bf-1f58b45e1fc7@rwec.co.uk>
Content-Language: en-GB
In-Reply-To: <69a5258d-05e4-420e-b4bf-1f58b45e1fc7@rwec.co.uk>
From: bilge@scriptfusion.com (Bilge)

This is a multi-part message in MIME format.
--------------wbt7nPAKhVRi7Q4B3TyjbfHT
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 25/08/2024 18:12, Rowan Tommins [IMSoP] wrote:
>
> For instance, rather than adding "default" to the "expr" rule in the 
> grammar, and then restricting it at compile-time, maybe we add a new 
> grammar rule "expr_with_default", usable only in expressions and with 
> a very limited set of productions.
>
Like the original commit 
<https://github.com/php/php-src/pull/15437/commits/fd7ac5f83b8282227235095843cb73e9d66b0717#diff-3e6742a9069b5717cf961c9d6b2aefbd1c730869d8a58123b1b5f3bc3e9082fcR1329>? 
Yeah, we did that.
>
> Just because it's easy to implement a feature a particular way, 
> doesn't mean that's necessarily the right way.
>
With respect, you do not know what you're talking about here. The 
original approach was to start manually whitelisting each expression 
grammar I thought made sense. THAT was the easiest way because both 
myself an Ilija failed in our first attempts to expand the grammar to 
support default as a general expression, and not for lack of trying. It 
took a Bison grammar expert to drop a patch that certainly wowed me, 
because hitherto I wasn't even certain it was possible, mainly because 
of the conflicts with `match` (but also `switch` to some extent). Aside, 
with respect to match, there is still an unresolved case and the RFC 
needs updating with the semantics we want to enforce there. So we 
pursued default as an expression not because it was easy, but despite 
the fact that it was hard, because it was precisely what we wanted to do.

I apologise for coming on strong, but I put a lot of effort into this, 
so I take exception to the implication that anyone involved took the 
easy way out to arrive at this (our best) solution.

Kind regards,
Bilge

--------------wbt7nPAKhVRi7Q4B3TyjbfHT
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 18:12, Rowan Tommins
      [IMSoP] wrote:</div>
    <blockquote type="cite"
      cite="mid:69a5258d-05e4-420e-b4bf-1f58b45e1fc7@rwec.co.uk">
      <p>For instance, rather than adding "default" to the "expr" rule
        in the grammar, and then restricting it at compile-time, maybe
        we add a new grammar rule "expr_with_default", usable only in
        expressions and with a very limited set of productions.<br>
      </p>
    </blockquote>
    Like the <a
href="https://github.com/php/php-src/pull/15437/commits/fd7ac5f83b8282227235095843cb73e9d66b0717#diff-3e6742a9069b5717cf961c9d6b2aefbd1c730869d8a58123b1b5f3bc3e9082fcR1329">original
      commit</a>? Yeah, we did that.<br>
    <blockquote type="cite"
      cite="mid:69a5258d-05e4-420e-b4bf-1f58b45e1fc7@rwec.co.uk">
      <p> </p>
      <p>Just because it's easy to implement a feature a particular way,
        doesn't mean that's necessarily the right way.<br>
      </p>
    </blockquote>
    <p>With respect, you do not know what you're talking about here. The
      original approach was to start manually whitelisting each
      expression grammar I thought made sense. THAT was the easiest way
      because both myself an Ilija failed in our first attempts to
      expand the grammar to support default as a general expression, and
      not for lack of trying. It took a Bison grammar expert to drop a
      patch that certainly wowed me, because hitherto I wasn't even
      certain it was possible, mainly because of the conflicts with
      `match` (but also `switch` to some extent). Aside, with respect to
      match, there is still an unresolved case and the RFC needs
      updating with the semantics we want to enforce there. So we
      pursued default as an expression not because it was easy, but
      despite the fact that it was hard, because it was precisely what
      we wanted to do.</p>
    <p>I apologise for coming on strong, but I put a lot of effort into
      this, so I take exception to the implication that anyone involved
      took the easy way out to arrive at this (our best) solution.<br>
    </p>
    <p>Kind regards,<br>
      Bilge<br>
    </p>
  </body>
</html>

--------------wbt7nPAKhVRi7Q4B3TyjbfHT--