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

On 11 April 2023 13:01:08 BST, Dan Ackroyd <Danack@basereality.com> wrote: >On Tue, 11 Apr 2023 at 09:48, Rowan Tommins <rowan.collins@gmail.com> wrote: >> >> Similarly, I think it should be possible to "unpin" a function >> lookup with a later definition, > >Can you say what the technical justification for that is? Perhaps "should" is too strong, but I would find it surprising if *using* a global function made it impossible to *define* a namespaced one. As I said in my previous message, there is a fundamental difference between caching of unprefixed name lookups, and actual function definitions. The current fallback and caching can always be skipped by using a fully qualified name. If additional caching is achieved using a dummy entry in the function table, a real entry for that function should be able to evict it, so that a fully-qualified function name can still be used. >Lots of things are possible, but I'd strongly prefer to have that be a >separate discussion, which it's listed as a future scope: >https://wiki.php.net/rfc/core-autoloading#higher_performance_through_maps > >If nothing else, it's going to take people time to figure out how they >are going to organise code that is 'just' a bunch of functions. I'm not talking about full mapping from name to file, or about functions specifically, but about a lot of existing autoloaders beginning with boilerplate like "if ( ! str_starts_with('Acme\\Foo\\') ) { return; }", and then whatever logic is used for loading Acme\Foo classes. If the core implementation can perform that check, it can skip the context switch to userland code. That's a benefit to the class autoloading anyway, but I'd be very surprised if function autoloaders looked any different, because that separation of ownership is pretty much what namespaces are *for*. Regards, -- Rowan Tommins [IMSoP]