Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125294
Content-Type: multipart/alternative;
 boundary="------------Hn0ioFyWqaH4k080SjdQepEA"
Message-ID: <d686f00c-ac41-460e-94fa-0a3041162f23@scriptfusion.com>
Date: Mon, 26 Aug 2024 22:57:04 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Default expression
To: internals@lists.php.net
References: <CAJp_myV3Riup2DyDWjgpHypDE6qP03Ogzdr6mZo6wWUmCtx16g@mail.gmail.com>
 <E1458589-B95C-43D0-A654-F8DB75782AB7@getmailspring.com>
 <CAJp_myXPpgmxkJautxUiADLz_fgVNv4RJSkpz_duAao9acSojA@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAJp_myXPpgmxkJautxUiADLz_fgVNv4RJSkpz_duAao9acSojA@mail.gmail.com>
From: bilge@scriptfusion.com (Bilge)

This is a multi-part message in MIME format.
--------------Hn0ioFyWqaH4k080SjdQepEA
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 26/08/2024 22:27, Matthew Weier O'Phinney wrote:
> Again, there are a few lists going around on this thread, and I hope 
> that Bilge is taking notes to add to the RFC, and working with the 
> folks who helped him with implementation to determine what is and is 
> not possible in terms of the grammar so we can potentially exclude the 
> more problematic ones.
>
I am just about to amend the RFC with the major discussion points from 
detractors, however I am still missing a list of even one item that must 
absolutely be prohibited, along with an explanation as to why.

FWIW, I have had the grand fortune to work with, or receive direct 
feedback from, some of the most talented PHP heads in the scene (read: 
engine maintainers) and they (so far) have unanimously confessed they do 
not see any issue with any permutation of default as an expression. 
Indeed, the entire point of the expression grammar is they can be 
composed freely with one another in any way you like; to do otherwise 
would be radical departure from the intended behaviour.

In case it matters, my initial inclination was also to do what some 
others have suggested, and modify the SEND opcodes so that the default 
is not actually looked up using reflection at all, but rather we just 
send nothing to the function and it can use its default as it would 
normally, but since I had the good sense to ask an engine maintainer how 
they would approach this problem, they cautioned me that this was the 
approach Stas took 10 years ago 
<https://github.com/php/php-src/compare/master...smalyshev:php-src:skip_params7>, 
that that approach was horrendous (paraphrasing) and they would never 
support something like that (mainly because there's like 11 of them and 
modifying them all would be a complete mess). So whilst you might find 
me quite unmoved by some of the arguments put forth on the mailing list 
and generally difficult to convince, it is not because I am stubborn in 
my naivete, it is because when wisdom was imparted, I listened. I am but 
a small man standing on the shoulders of giants.

Kind regards,
Bilge

--------------Hn0ioFyWqaH4k080SjdQepEA
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 26/08/2024 22:27, Matthew Weier
      O'Phinney wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAJp_myXPpgmxkJautxUiADLz_fgVNv4RJSkpz_duAao9acSojA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>Again, there are a few lists going around on this thread,
            and I hope that Bilge is taking notes to add to the RFC, and
            working with the folks who helped him with implementation to
            determine what is and is not possible in terms of the
            grammar so we can potentially exclude the more problematic
            ones.</div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
    <p>I am just about to amend the RFC with the major discussion points
      from detractors, however I am still missing a list of even one
      item that must absolutely be prohibited, along with an explanation
      as to why.</p>
    <p>FWIW, I have had the grand fortune to work with, or receive
      direct feedback from, some of the most talented PHP heads in the
      scene (read: engine maintainers) and they (so far) have
      unanimously confessed they do not see any issue with any
      permutation of default as an expression. Indeed, the entire point
      of the expression grammar is they can be composed freely with one
      another in any way you like; to do otherwise would be radical
      departure from the intended behaviour.</p>
    <p>In case it matters, my initial inclination was also to do what
      some others have suggested, and modify the SEND opcodes so that
      the default is not actually looked up using reflection at all, but
      rather we just send nothing to the function and it can use its
      default as it would normally, but since I had the good sense to
      ask an engine maintainer how they would approach this problem,
      they cautioned me that this was <a
href="https://github.com/php/php-src/compare/master...smalyshev:php-src:skip_params7">the
        approach Stas took 10 years ago</a>, that that approach was
      horrendous (paraphrasing) and they would never support something
      like that (mainly because there's like 11 of them and modifying
      them all would be a complete mess). So whilst you might find me
      quite unmoved by some of the arguments put forth on the mailing
      list and generally difficult to convince, it is not because I am
      stubborn in my naivete, it is because when wisdom was imparted, I
      listened. I am but a small man standing on the shoulders of
      giants.</p>
    <p>Kind regards,<br>
      Bilge<br>
    </p>
  </body>
</html>

--------------Hn0ioFyWqaH4k080SjdQepEA--