Re: [RFC] New core autoloading mec hanism with support for function autoloading

On 11 April 2023 12:16:18 BST, "G. P. B." <george.banyard@gmail.com> wrote: > >However, we *already* do function pinning which can result in this >behaviour via the function cache, see the following bug which defines a new >function via eval(): >https://bugs.php.net/bug.php?id=64346 That's not the same thing - that's pinning *the meaning of an unprefixed name within a particular scope*, my example was of using *a fully-qualified function name*, of a function that has never been defined. Substituting a fully-qualified name in the example from that bug runs the namespaced function just fine: https://3v4l.org/tReC3 >I am not sure that it calling the global strlen() is that surprising, as it >is basically aliasing the function \Foo\strlen() to \strlen(). That's the implementation detail that I'm saying should not leak. It is not the current semantics of function lookups, and I don't think it's desirable semantics. >> Similarly, I think it should be possible to "unpin" a function lookup with >> a later definition, even if no autoloading would be triggered. That is, >> this should not be a duplicate definition error: >> >> namespace Foo; >> if ( strlen('magic') != 42 ) { >> function strlen($string) { /* ... */ } >> } >> > >There are some larger technical issues at play, as mentioned in the >previous bug. The above code doesn't currently generate an error, and the function defined is callable with and without prefix: https://3v4l.org/nPbat If I understand right, the caching issue is that some uses of unprefixed strlen(...) might not pick up the new function; but fully qualified uses will reliably do so. >That is actually interesting, hadn't thought about taking an array of >prefixes. >And yes, every callback call requires a VM re-entry, which is expensive. > >Should the prefix be with or without the trailing backlash? It would probably make sense to follow Composer's lead and require it; their reasoning seems sound (from https://getcomposer.org/doc/04-schema.md#psr-4): > Namespace prefixes must end in \\ to avoid conflicts between similar prefixes. For example Foo > would match classes in the FooBar namespace so the trailing backslashes solve the problem: Foo\\ and > FooBar\\ are distinct. Regards, -- Rowan Tommins [IMSoP]