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

 Time for a contrary opinion.  I think there has been too much
 [http://www.psysr.org/about/pubs_resources/groupthink%20overview.htm group
 think] on this ticket ''(except for @azaozz)''.


 > Composer

 I assume we are discussing how the average WordPress would work with
 WordPress. For that I am currently strongly against using Composer for
 WordPress core.  First, it's autoloader.

 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 is relevant not just for performance but because it makes debugging
 with XDEBUG a '''major PITA'''.  Our autoloader is two lines long using a
 classmap, and it is far less painful to use when XDEBUGging.

 Second is Composer's complexity

 I think we should reinvent the wheel here.  I have been working the past
 year on WPLib Box (Vagrant local dev server) with a goal of creating a
 standized platform for doing WP development -- at least for users of our
 box -- I had embraced Composer.

 However, recently I have come to the conclusion that while Composer is
 brilliant for PHP frameworks it is a nightmare to work with for WordPress
 because it is opinionated in many ways and those opinions different in
 most things that WordPress needs to do.

 So I am now planning to design a WordPress-specific format for WPLib Box
 with a goal to greatly simplify what you need to specify to get a WP site
 to work. We might even generate a Composer file and use it behind the
 scenes, merging in any Composer files that work well with Composer, e.g.
 those things found at packagist.org.

 That said, I would love for the WordPress community to do this work with
 me so it it can be improved by me not working on it in a vacuum.

 '''In summary related to Composer is that it is not well suited for
 WordPress website.'''

 '''And I would hate to see Composer become the ''"standard"'' for
 WordPress.'''

 > Too Much Code Running During Autoloading

 '''My preference would be that WordPres core would leverage a highly-
 optimized class-map autoloader''' ''(and not have the classmap be
 "temporary")'' used both for performance and for minimizing amount of code
 that one has to step through during debugging with XDEBUG, and encourage
 plugins and themes to use the class-map too.

 Ideally the class-map autoloader would be optimized for the number of
 lines that need to run for a file to be autoloaded, and that the class-map
 loader would be run first in front of the other optional autoloaders.  And
 rather than separating concerns for the class-map loader, optimize it
 instead.

 > class-foo-bar.php vs. WP_Foo_Bar.php

 I started our WPLib autoloader following that pattern, but am currently
 working on a version that will move to using classnames for filenames
 because it solves the problem of to find the filename for a class in a
 classmap. This is very helpful when writing code that needs to be able to
 determine what plugin a class is in, or if it in the theme, for example.


 > Class-Map Generation.
 BTW, I've found a really nice way to build a class-map even with the other
 autoloaders.  Have each autoloader add any classes found to the classmap
 and then when WP_DEBUG` is active write out to a file on a `'shutdown'`
 hook which can then be loaded in wp-settings.php. Which it works well for
 WPLib there are issues with implementing it in core, but it is something
 to explore.

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