Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125317
Content-Type: multipart/alternative;
 boundary="------------TcHp0VJFG9ZgBJc8TjVsb05P"
Message-ID: <ff8af596-6660-4871-8aad-60fc392189e0@scriptfusion.com>
Date: Tue, 27 Aug 2024 14:14:03 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Default expression
To: Derick Rethans <derick@php.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com>
 <ddc026b1-3cfd-03fe-1cd3-3a6930ed2c22@php.net>
Content-Language: en-GB
In-Reply-To: <ddc026b1-3cfd-03fe-1cd3-3a6930ed2c22@php.net>
From: bilge@scriptfusion.com (Bilge)

This is a multi-part message in MIME format.
--------------TcHp0VJFG9ZgBJc8TjVsb05P
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 27/08/2024 12:56, Derick Rethans wrote:
> Using 'default' as a place holder for (not) passing an argument seems
> useful. I am however much uncertain about using composition with the
> keyword in expressions.
Presumably you mean ternary and null coalesce would still be acceptable? 
Otherwise, it is little more than an alternative to named parameters, 
which is seldom useful. Ternary and null coalesce are, themselves, 
expressions so I expect that is why I was guided towards treating 
`default` the same way. Whilst the applications beyond use in 
conditionals still strikes me as limited, it also appears equally 
harmless.  Though the number of people whom feel its use in expression 
should be limited is steadily growing, I'm still waiting on someone to 
publish an exclusion list with justification for each exclusion, because 
again, I think a plurality of possibilities are harmless. Nevertheless, 
an inclusion list was produced by IMSoP, based on what he felt would be 
useful, but I think arbitrary exclusions are unintuitive for developers 
and likely to limit someone from doing something justifiably useful that 
we didn't conceive at the time.
> I also think that implementation would probably be significantly less
> complex as it was only used for placeholders.
Would it? I was told that the alternative was to modify all the SEND 
opcodes, which is anything but less complex. The current implementation 
seems necessarily simple to me since it just adds a single new opcode 
that doesn't interfere with anything else. I say necessarily, because if 
it was actually complex, I probably couldn't have written the solution 
given my limited ability.
>   It's likely something that can be handled in the parser.

Clearly this problem cannot be solved solely in the parser. If I assume 
you're proposing to just allow `default` in conditionals, what is 
responsible for compiling that and how will the called function know 
what to do with it?

Cheers,
Bilge

--------------TcHp0VJFG9ZgBJc8TjVsb05P
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 27/08/2024 12:56, Derick Rethans
      wrote:<span style="white-space: pre-wrap">
</span><span style="white-space: pre-wrap">
</span></div>
    <blockquote type="cite"
      cite="mid:ddc026b1-3cfd-03fe-1cd3-3a6930ed2c22@php.net">
      <pre class="moz-quote-pre" wrap="">Using 'default' as a place holder for (not) passing an argument seems 
useful. I am however much uncertain about using composition with the 
keyword in expressions.</pre>
    </blockquote>
    Presumably you mean ternary and null coalesce would still be
    acceptable? Otherwise, it is little more than an alternative to
    named parameters, which is seldom useful. Ternary and null coalesce
    are, themselves, expressions so I expect that is why I was guided
    towards treating `default` the same way. Whilst the applications
    beyond use in conditionals still strikes me as limited, it also
    appears equally harmless.  Though the number of people whom feel its
    use in expression should be limited is steadily growing, I'm still
    waiting on someone to publish an exclusion list with justification
    for each exclusion, because again, I think a plurality of
    possibilities are harmless. Nevertheless, an inclusion list was
    produced by IMSoP, based on what he felt would be useful, but I
    think arbitrary exclusions are unintuitive for developers and likely
    to limit someone from doing something justifiably useful that we
    didn't conceive at the time.<span style="white-space: pre-wrap">
</span><span style="white-space: pre-wrap">
</span>
    <blockquote type="cite"
      cite="mid:ddc026b1-3cfd-03fe-1cd3-3a6930ed2c22@php.net">
      <pre class="moz-quote-pre" wrap="">I also think that implementation would probably be significantly less 
complex as it was only used for placeholders.</pre>
    </blockquote>
    Would it? I was told that the alternative was to modify all the SEND
    opcodes, which is anything but less complex. The current
    implementation seems necessarily simple to me since it just adds a
    single new opcode that doesn't interfere with anything else. I say
    necessarily, because if it was actually complex, I probably couldn't
    have written the solution given my limited ability.<br>
    <blockquote type="cite"
      cite="mid:ddc026b1-3cfd-03fe-1cd3-3a6930ed2c22@php.net">
      <pre class="moz-quote-pre" wrap=""> It's likely something that can be handled in the parser.</pre>
    </blockquote>
    <p>Clearly this problem cannot be solved solely in the parser. If I
      assume you're proposing to just allow `default` in conditionals,
      what is responsible for compiling that and how will the called
      function know what to do with it?</p>
    <p>Cheers,<br>
      Bilge<br>
    </p>
  </body>
</html>

--------------TcHp0VJFG9ZgBJc8TjVsb05P--