On 11 April 2023 12:16:18 BST, "G. P. B." <george.bany...@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]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to