Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126075
Message-ID: <8e0d5c13-07ae-4357-88c2-f7f9bb54f614@bastelstu.be>
Date: Wed, 27 Nov 2024 22:58:39 +0100
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [VOTE] Support Closures in constant expressions
To: Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>,
 internals@lists.php.net
Cc: volker@tideways-gmbh.com
References: <ac811e734b7a5c6acc88f89ee14d0574@bastelstu.be>
 <6a1940027c8c534e62bfb13d222947bf@bastelstu.be>
 <67479414.8070302@adviesenzo.nl>
Content-Language: en-US
In-Reply-To: <67479414.8070302@adviesenzo.nl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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