Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119909
Date: Tue, 11 Apr 2023 12:45:47 +0100
To: "G. P. B." <george.banyard@gmail.com>
CC: internals@lists.php.net
User-Agent: K-9 Mail for Android
In-Reply-To: <CAFPFaMLLLKDbs7xtykgibrD_FyjLv98f_sjDw650bHyVWKyg2g@mail.gmail.com>
References: <CAFPFaMLghRYP4ioCkfa7WKhTAz+1gWgcZ5mWYAunkb9f3g=fdA@mail.gmail.com> <6FA5AA43-9738-4400-8D83-38FC2D464B82@gmail.com> <CAFPFaMLLLKDbs7xtykgibrD_FyjLv98f_sjDw650bHyVWKyg2g@mail.gmail.com>
Message-ID: <63FB2A01-481C-47B9-BD43-2BF29682F372@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: =?US-ASCII?Q?Re=3A_=5BPHP-DEV=5D_=5BRFC=5D_New_core_autoloading_mec?= =?US-ASCII?Q?hanism_with_support_for_function_autoloading?=
From: rowan.collins@gmail.com (Rowan Tommins)

On 11 April 2023 12:16:18 BST, "G=2E P=2E B=2E" <george=2Ebanyard@gmail=2Ec=
om> wrote:
>
>However, we *already* do function pinning which can result in this
>behaviour via the function cache, see the following bug which defines a n=
ew
>function via eval():
>https://bugs=2Ephp=2Enet/bug=2Ephp?id=3D64346


That's not the same thing - that's pinning *the meaning of an unprefixed n=
ame within a particular scope*, my example was of using *a fully-qualified =
function name*, of a function that has never been defined=2E

Substituting a fully-qualified name in the example from that bug runs the =
namespaced function just fine: https://3v4l=2Eorg/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()=2E


That's the implementation detail that I'm saying should not leak=2E It is =
not the current semantics of function lookups, and I don't think it's desir=
able semantics=2E



>> Similarly, I think it should be possible to "unpin" a function lookup w=
ith
>> a later definition, even if no autoloading would be triggered=2E That i=
s,
>> this should not be a duplicate definition error:
>>
>> namespace Foo;
>> if ( strlen('magic') !=3D 42 ) {
>>     function strlen($string) { /* =2E=2E=2E */ }
>> }
>>
>
>There are some larger technical issues at play, as mentioned in the
>previous bug=2E


The above code doesn't currently generate an error, and the function defin=
ed is callable with and without prefix: https://3v4l=2Eorg/nPbat

If I understand right, the caching issue is that some uses of unprefixed s=
trlen(=2E=2E=2E) might not pick up the new function; but fully qualified us=
es will reliably do so=2E=20



>That is actually interesting, hadn't thought about taking an array of
>prefixes=2E
>And yes, every callback call requires a VM re-entry, which is expensive=
=2E
>
>Should the prefix be with or without the trailing backlash?


It would probably make sense to follow Composer's lead and require it; the=
ir reasoning seems sound (from https://getcomposer=2Eorg/doc/04-schema=2Emd=
#psr-4):

> Namespace prefixes must end in \\ to avoid conflicts between similar pre=
fixes=2E For example Foo would match classes in the FooBar namespace so the=
 trailing backslashes solve the problem: Foo\\ and FooBar\\ are distinct=2E


Regards,

--=20
Rowan Tommins
[IMSoP]