On 11 April 2023 12:16:18 BST, "G. P. B." <[email protected]> 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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
