Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125226
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------pxl8dKxIYEXgQJmdSK4WLiGL"
Message-ID: <69a5258d-05e4-420e-b4bf-1f58b45e1fc7@rwec.co.uk>
Date: Sun, 25 Aug 2024 18:12:02 +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>
Content-Language: en-GB
In-Reply-To: <CAPyj-LDLsHYcnAuka9OLdb3_YXd1_1yjvj+xvYuJYUKWpk61SQ@mail.gmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------pxl8dKxIYEXgQJmdSK4WLiGL
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 25/08/2024 17:36, Ilija Tovilo wrote:
> I don't agree with that. Constant expressions in PHP already only
> support a subset of operations that expressions do. However, default
> is proposed to be a true expression, i.e. one that compiles to
> opcodes.


This is circular: obviously, changing the proposal requires making 
changes to what is proposed.

I'm arguing that allowing default as a token that's usable in arbitrary 
expressions is unnecessary and problematic, and that we should instead 
define the specific use cases, and build the feature around those.


> I also believe some of the rules you've laid out would be hard to enforce.


The rules were intended to guide the design of the feature, not be 
things that someone needed to enforce in code somewhere. If you start 
with the aim of implementing:

- Use in place of an argument
- Use with bitwise | and &
- Use on the RHS of ?: and ??

Then maybe you end up with a completely different implementation from 
what's currently been written.

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. Maybe that means we can't support 
match() expressions, because it would bloat the grammar too much, but 
"match($foo) { 'blah'=> 'bleugh', default => default }" is pretty ugly 
anyway.

Or maybe, the expressions are allowed, but they're compiled down with 
"default" as a special pseudo-type that has limited legal operations, so 
that the result of "(int)default" is undefined, no matter how you try to 
obfuscate it.


Just because it's easy to implement a feature a particular way, doesn't 
mean that's necessarily the right way.


-- 
Rowan Tommins
[IMSoP]

--------------pxl8dKxIYEXgQJmdSK4WLiGL
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 17:36, Ilija Tovilo
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAPyj-LDLsHYcnAuka9OLdb3_YXd1_1yjvj+xvYuJYUKWpk61SQ@mail.gmail.com">
      <pre>I don't agree with that. Constant expressions in PHP already only
support a subset of operations that expressions do. However, default
is proposed to be a true expression, i.e. one that compiles to
opcodes.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>This is circular: obviously, changing the proposal requires
      making changes to what is proposed.</p>
    <p>I'm arguing that allowing default as a token that's usable in
      arbitrary expressions is unnecessary and problematic, and that we
      should instead define the specific use cases, and build the
      feature around those.<br>
    </p>
    <p><br>
    </p>
    <p>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">I also believe some of the rules you've laid out would be hard to enforce.</pre>
      </blockquote>
    </p>
    <p><br>
    </p>
    <p>The rules were intended to guide the design of the feature, not
      be things that someone needed to enforce in code somewhere. If you
      start with the aim of implementing:</p>
    <p>- Use in place of an argument<br>
      - Use with bitwise | and &amp;<br>
      - Use on the RHS of ?: and ??</p>
    <p>Then maybe you end up with a completely different implementation
      from what's currently been written.</p>
    <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. Maybe that means we
      can't support match() expressions, because it would bloat the
      grammar too much, but "match($foo) { 'blah'=&gt; 'bleugh', default
      =&gt; default }" is pretty ugly anyway.<br>
    </p>
    <p>Or maybe, the expressions are allowed, but they're compiled down
      with "default" as a special pseudo-type that has limited legal
      operations, so that the result of "(int)default" is undefined, no
      matter how you try to obfuscate it.</p>
    <p><br>
    </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>
    <p><br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------pxl8dKxIYEXgQJmdSK4WLiGL--