Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113984
To: internals@lists.php.net
References: <php.internals-113545@news.php.net>
 <606b899b.1c69fb81.8d941.72beSMTPIN_ADDED_MISSING@mx.google.com>
Message-ID: <27144603-7a8c-be3d-72f2-3e9246d4da85@seld.be>
Date: Wed, 7 Apr 2021 11:05:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <606b899b.1c69fb81.8d941.72beSMTPIN_ADDED_MISSING@mx.google.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: [PHP-DEV] Re: [RFC] Autoloader Classmap
From: j.boggiano@seld.be (Jordi Boggiano)

Hi Mark,

On 06/04/2021 00:05, Mark Randall wrote:
>
> * I expect 99.9999% of users will never know it exists, and it will 
> instead just be an option for tools like composer that will provide a 
> small transparent boost.
>
I wrote this as feedback in your early round (I don't think you 
answered), and IMO it still stands:

//

The proposed API should really support
multiple maps. Composer has a  prepend-autoloader option which controls
whether the generated autoloader will be prepended or appended when
spl_autoload_register is called. This is required in some cases where
multiple autoloaders coexist. So the ability to add multiple maps,
including optionally prepending them would be a must IMO. The ability to
remove an autoloader and its associated classmap would also be very
welcome so one can unregister things cleanly.

So taking the above in consideration, and keeping consistency with
existing spl_* functions in mind, I would propose an API more like:

     autoload_register_classmap(array $map, bool $prepend = false)
     autoload_unregister_classmap(array $map)

//

Given the current API proposal, I think I would vote no, because I do 
not know how I'd even implement this in Composer without making a mess 
in case multiple autoloaders co-exist (which one can not know about at 
autoload generation time). We'd have to perhaps set the classmap on the 
first autoloader, and if a second autoloader gets created it'd wipe the 
classmap entirely and skip the optimization for safety because it 
becomes unmanageable otherwise.


> * It provides a very minor benefit to debugging as you get to skip 
> over the autoloading frames which so very often come up during a request.
>
In development environment we do not recommend using an optimized 
autoloader as it slows down updates/installs and doesn't bring a ton of 
perf benefit, so this argument isn't that strong.

Best,
Jordi