[wp-trac] [WordPress Trac] #36335: Next generation: core autoloader proposal

[WordPress Trac]

#36335: Next generation: core autoloader proposal
-----------------------------+-----------------------------
 Reporter:  dnaber-de        |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Future Release
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+-----------------------------
Changes (by rmccue):

 * milestone:  Awaiting Review => Future Release


Comment:

 FYI, we can actually polyfill autoloader registration. The way autoloaders
 work in PHP is that PHP runs the `__autoload()` function, or rather, it
 looks the `__autoload` symbol up and executes it. When SPL is enabled, it
 actually reaches into PHP's internals and swaps the existing `__autoload`
 out for its own implementation, keeping a reference to the previous
 function.

 We can replicate this:
 {{{
 if ( ! function_exists( 'spl_autoload_register' ) ):
 function __autoload( $class ) {
     global $wp_registered_autoloaders;
     foreach ( $wp_registered_autoloaders as $autoloader ) {
         call_user_func( $autoloader, $class );
         if ( class_exists( $class, false ) ) {
             break;
         }
     }
 }

 function spl_autoload_register( $autoloader ) {
     global $wp_registered_autoloaders;
     $wp_registered_autoloaders[] = $autoloader;
 }
 endif;
 }}}

 (It requires that we're the first to declare `__autoload`, but that
 shouldn't be an issue 99% of the time.)

 ----

 As to the issue of whether we want an autoloader or not, profiling has
 been done in the past as to whether it'd be useful or not, and the finding
 then was that including the files we're definitely going to need turned
 out better. I don't know the exact results, since it's important to
 remember that autoloading is a time/memory tradeoff; loading all files
 might take less time, but significantly more memory.

 I think a staged approach to this is the best way. Firstly, let's make
 every class that's not always loaded (wp-admin, etc) loadable via
 autoloading. This is probably a large task in itself, as we need to switch
 to one-class-per-file with predictable file naming.

 Once that's done, stage 2 should be working out which classes are part of
 the critical path (i.e. required for every page load). Those that aren't
 can be switched to autoloading.

 I strongly support this idea; thanks for proposing it :)

--
Ticket URL: <https://core.trac.wordpress.org/ticket/36335#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform