Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125052
Feedback-ID: id5114917:Fastmail
Message-ID: <6197f6e1-d123-41e1-87c8-887c6508bfa2@rwec.co.uk>
Date: Mon, 19 Aug 2024 22:17:19 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] function autoloading v4 RFC
To: internals@lists.php.net
References: <2716f729-4008-4f75-8412-861d8960b746@app.fastmail.com>
 <cOoRTbvWeeI8DDj531R9b7NwiyLusi5oHFI_0FmZeOx-R5bs1dUC7VO5ZypChYBECwA8SBzrpEABGGH0mPKrLDsYMSfrhuZX2Gn6zUyP4fI=@gpb.moe>
 <26338153-6d16-456a-81bf-8231bdaf1b79@app.fastmail.com>
Content-Language: en-GB
In-Reply-To: <26338153-6d16-456a-81bf-8231bdaf1b79@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 19/08/2024 17:23, Rob Landers wrote:

> As far as performance for ambiguous functions go, I was thinking of 
> submitting an RFC, where ambiguous function calls are tagged during 
> compilation and always resolve lexically, sorta like how it works now:
>
> echo strlen($x); // resolves to global, always
> require_once "my-strlen";
> echo strlen($x); // resolves to my strlen, always
>
> This works by basically rewriting the function name once resolved and 
> may make the code more predictable. If I can pull it off, it can be 
> relegated to a technical change that doesn’t need an RFC. Still 
> working on it.


I'm not entirely clear what you're suggesting, but I think it might be 
either what already happens, or the same as Gina is proposing.

Consider this code [https://3v4l.org/184k3]:

namespace Foo;

foreach ( [1,2,3] as $i ) {
      echo strlen('hello'), ' ';
      shadow_strlen();
      echo strlen('hello'), '; ';
}

function shadow_strlen() {
     if ( ! function_exists('Foo\\strlen') ) {
         function strlen($s) {
             return 42;
         }
     }
}

In PHP 5.3, this outputs '5 42; 42 42; 42 42;'  That's fairly 
straight-forward: each time the function is called, the engine checks if 
"Foo\strlen" is defined.

Since PHP 5.4, it outputs '5 42; 5 42; 5 42;'   The engine caches the 
result of the lookup against each compiled opcode, so the first strlen() 
is cached as a call to \strlen() and the second as a call to \Foo\strlen().

As I understand it, Gina is proposing that it would instead output '5 5; 
5 5; 5 5;' - the function would be "pinned" by making "\Foo\strlen" an 
alias to "\strlen" for the rest of the program, and the function_exists 
call would immediately return true.

Neither, as far as I can see, can happen at compile time, because the 
compiler doesn't know if and when a definition of \Foo\strlen() will be 
encountered.


> In other words, maybe pinning could be solved more generally in a 
> future RFC, decrease your RFC’s scope and chance for sharp edge cases.

If anything, I think it would need to be the other way around: change 
the name resolution logic, so that an autoloading proposal was more 
palatable, because it didn't require running the autoloader an unbounded 
number of times for the same name.

Proposing both at once seems reasonable, as the autoloading gives an 
extra benefit to outweigh the breaking change to shadowing behaviour.

Regards,

-- 
Rowan Tommins
[IMSoP]