Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126076
Subject: Re: [PHP-DEV] [VOTE] Support Closures in constant expressions
To: =?UTF-8?Q?Tim_D=c3=bcsterhus?= <tim@bastelstu.be>, internals@lists.php.net
References: <ac811e734b7a5c6acc88f89ee14d0574@bastelstu.be>
 <6a1940027c8c534e62bfb13d222947bf@bastelstu.be>
 <67479414.8070302@adviesenzo.nl>
 <8e0d5c13-07ae-4357-88c2-f7f9bb54f614@bastelstu.be>
Cc: volker@tideways-gmbh.com
Message-ID: <6747979E.5090401@adviesenzo.nl>
Date: Wed, 27 Nov 2024 23:05:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <8e0d5c13-07ae-4357-88c2-f7f9bb54f614@bastelstu.be>
Content-Type: multipart/alternative;
 boundary="------------010302000809010703040105"
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

This is a multi-part message in MIME format.
--------------010302000809010703040105
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 27-11-2024 22:58, Tim Düsterhus wrote:
> Hi
>
> On 11/27/24 22:50, Juliette Reinders Folmer wrote:
>> One thing I'm wondering about - and of which I saw no mention in the RFC
>> nor in the preceding discussion - knowing that function names are
>> case-insensitive, how is ambiguity handled when _calling_ a callback
>> stored in a (class) constant ?
>
> Nothing changed about the grammar or the way a PHP program is parsed 
> into Opcodes. As mentioned in the RFC it does not include any 
> backwards incompatible changes, except for making some illegal PHP 
> programs legal.
>
> In fact you are already able to store Closures in dynamic constants 
> defined with the `define()` function (https://3v4l.org/u7ZJ1).
>
> In any case that means that all your examples are interpreted as 
> function calls. You need parentheses around the constant name to 
> "dereference" the value stored in the constant. This is consistent 
> with $obj->foo() always being a method call to the foo() method, not a 
> call to a Closure stored in a property called $foo.
>
> Best regards
> Tim Düsterhus
>

Thanks for the clarification. Might be good to mention this in the 
documentation eventually.

--------------010302000809010703040105
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 27-11-2024 22:58, Tim Düsterhus wrote:<br>
    <blockquote
      cite="mid:8e0d5c13-07ae-4357-88c2-f7f9bb54f614@bastelstu.be"
      type="cite">Hi
      <br>
      <br>
      On 11/27/24 22:50, Juliette Reinders Folmer wrote:
      <br>
      <blockquote type="cite">One thing I'm wondering about - and of
        which I saw no mention in the RFC
        <br>
        nor in the preceding discussion - knowing that function names
        are
        <br>
        case-insensitive, how is ambiguity handled when _calling_ a
        callback
        <br>
        stored in a (class) constant ?
        <br>
      </blockquote>
      <br>
      Nothing changed about the grammar or the way a PHP program is
      parsed into Opcodes. As mentioned in the RFC it does not include
      any backwards incompatible changes, except for making some illegal
      PHP programs legal.
      <br>
      <br>
      In fact you are already able to store Closures in dynamic
      constants defined with the `define()` function
      (<a class="moz-txt-link-freetext" href="https://3v4l.org/u7ZJ1">https://3v4l.org/u7ZJ1</a>).
      <br>
      <br>
      In any case that means that all your examples are interpreted as
      function calls. You need parentheses around the constant name to
      "dereference" the value stored in the constant. This is consistent
      with $obj-&gt;foo() always being a method call to the foo()
      method, not a call to a Closure stored in a property called $foo.
      <br>
      <br>
      Best regards
      <br>
      Tim Düsterhus
      <br>
      <br>
    </blockquote>
    <br>
    Thanks for the clarification. Might be good to mention this in the
    documentation eventually.<br>
  </body>
</html>

--------------010302000809010703040105--