[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 MikeSchinkel):

 Replying to [comment:194 TJNowell]:
 > Mike has indicated he wanted to work on an autoloader proof of concept
 but didn't have time in that week. Now that time has passed, I'm curious
 to see what he's devised.

 Sorry, life got in the way ''(clients, WordCamp, etc. etc.)''

 I have implemented the autoloader ''(which took ~10 minutes)'', reworked
 the classmap generator ''(~30 minutes)'' and then refactored WordPress
 core so that as many classes could be autoloaded as reasonably possible
 ''(and that took over 8 hours.)''

 See attached patch [/attachment/ticket/36335/36335-autoloader.diff
 36335-autoloader.diff] which contains all the code mentioned.

 In order to get this actually done and working I took some liberties
 regarding and source files that had more than one class; I split them
 apart and created a new file for each of them.

 Given the work I've done on WPLib I've learned that working with an
 autoloader ends up being easier if the files names actually match the
 class names as opposed using a `class-` prefer with dashes and all
 lowercase; i.e. `WP_Query.php` instead of `class-wp-query.php`.  The main
 benefit is that you can do a directory scan and get the class nameswithout
 requiring any transform of the data.  So I renamed all of the class files
 to use the same name as the class.

 I also created two (2) `/autoload/` directories:  `/wp-includes/autoload`
 and `/wp-admin/autoload`.  I created subdirectories inside these autoload
 directories to organize the code better, e.g. `/wp-
 includes/autoload/filesystem` and `/wp-admin/customize/`, for example.

 In addition I created two (2) `/constants/` directories:  `/wp-
 includes/constants` and `/wp-admin/constants` which I used to move any
 constants that were defined in class files.  I load these constants in
 `/wp-includes/constants/default-constants.php` and `/wp-
 admin/constants/include/admin.php`, respectively.

 '''As for performance''', I do not have any benchmarks set up but I can
 honestly say '''it feels extremely snappy.'''  I would love it if someone
 who is good at benchmarks could try their hand and benchmarking this.

 Finally, '''this is a proof-of-concept''' for people to actually see what
 I have been proposing.  I have tested it in a cursory manner but I do not
 have WordPress' full test suite set up so it is highly likely to be broken
 in more than a few places.

 Still, '''there is a lot of work in here to separate out the classes to
 get them into a form that can be autoloaded''', even if we did ultimately
 choose a Composer autoloader, but '''this patch will become stale pretty
 quickly''' so if we want to move forward with this we would be '''best to
 make a decision sooner than later''' otherwise most of the work I did will
 have to be redone again on a future version of WordPress.

 P.S. I have not yet implemented automatic generation of the classmap on a
 shutdown hook as I mentioned in previous comments on this ticket.  I have
 used that approach with WPLib and it works extremely well in combination
 with a constant that you would only define during development, e.g.
 `WP_GENERATE_CLASSMAP`.

 But it might not be the best approach for core since the classmap
 generator could easily be run during a build step but it could be useful
 for those who would like to be able to autoload any classes in themes or
 plugins that are deployed via version control.

 It won't take long to add that code, but I'll wait to see if this approach
 gets traction before moving forward with this.

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