[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:  4.7
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:
-----------------------------+------------------

Comment (by schlessera):

 Replying to [comment:144 MikeSchinkel]:
 > For our own project (WPLib) we added our own autoloader in front of
 Composer's autoloader because Composer's autoloader often runs through a
 painful amount of code before it actually identifies the file to load.

 This made me curious, so I checked to see what the actual code path is for
 the proposed Composer class map autolaoder that was committed.

 First, let's check what function gets registered as the autoload callback:

 {{{#!php
 spl_autoload_register(array($this, 'loadClass'), true);
 }}}

 So, when a class is not yet known, the PHP autoloader will be invoked, and
 it will call the `ClassLoader::loadClass()` method. So far so good, not
 much to optimize there, as this is all PHP internals up to that point.

 It gets more interesting if we take a look at the code if this
 `loadClass()` method:

 {{{#!php
 public function loadClass($class)
 {
     if ($file = $this->findFile($class)) {
         include $file;
         return true;
     }
 }
 }}}

 It tries to find the needed file, includes it and returns. Not much to
 optimize here either.

 And then finally, let's take a look at the code path of the
 `ClassLoader::findFile()` method, provided that we're using a class map as
 is currently the case here:

 {{{#!php
 public function findFile($class)
 {
     if ('\\' === $class[0]) {
         $class = substr($class, 1);
     }

     if (isset($this->classMap[$class])) {
         return $this->classMap[$class];
     } // [...]
 }
 }}}

 So, it first makes sure to have a normalized class name, then retrieves it
 from the class map and returns.

 I don't think there's much potential for optimization in the code above,
 for the scenario we have been describing here.

 Yes, if the class was not found, the code continues, and yes, if you use
 different kinds of autoloaders, different code paths get executed. But as
 you mentioned you were using class maps, I fail to see how you optimized
 the above by prepending your own class loader.

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