[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:
-----------------------------+-----------------------------

Comment (by rmccue):

 I think whether we adopt Composer usage or not isn't hugely relevant to
 this conversation; while it has the ability to solve some of the problems
 here, it's also a huge architectural change to get it to the point where
 it would make sense. Let's discuss this on a new ticket rather than here.

 ----

 I do love the concept of autoloading, and I think the work here has been
 productive, but I don't think the current implementation is appropriate
 for core. It's a bit too heavy and general-purpose.

 I have an alternative implementation that tries to stay as lightweight as
 possible. It implements the bare minimum to support autoloading core
 itself, which is likely also useful for plugins, but isn't necessarily
 designed to be. We can look at expanding this in the future, but this is
 just a Minimal Viable Patch. I think we can all agree that some form of
 autoloading is better than what we have right now. :)

 The attached file contains ~70 lines of (undocumented) code that includes
 PSR-0, WP-style (`class-...php`) and classmap style autoloaders, plus ~170
 lines of configuration for core itself. (The rest of the code is to
 generate a table.) Note that this is just the lookup at the moment so we
 can get the mapping sorted first (adapting this to the actual autoloader
 will be only a line or two more). The `$wp_autoloaders` bit is temporary;
 in the final implementation, I'd rather we avoid treating the autoloaders
 any different to any other normal PHP autoloader. That is, let's use
 `spl_autoload_register` directly rather than implementing our own
 autoloading stack on top of it.

 [http://bl.ocks.org/rmccue/raw/9cf8f5d2987f1b98335f7003e654ae1f/e07bff5cdb322d870d63a1cdc4d790c145281634/
 Here's what that mapping looks like]. This covers the vast majority of
 classes in core, with some exceptions. The ones I haven't tackled here are
 mostly things we should split out, or are never going to be autoloaded.

 We can look at expanding and changing this in the future, but this takes
 us from no autoloading right now to having the key pieces we need for it.
 This is kind of like building demolition: we're assembling the scaffolding
 first to allow us to take the building down slowly. Once this is in place,
 we can start removing some of the `require` statements safely and
 evaluating how it affects core as we go.

 (I've also attached the autoloader compatibility file; you can check the
 consistency [https://3v4l.org/D69oU using 3v4l.org]. This should polyfill
 the SPL autoloader nicely.)

 I'd love to hear your thoughts on this alternative approach.

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