[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]:
 > 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)''.

 @azaozz raises very valid concerns, and I think we should try our best to
 address each one of them and find a solution that works for all concerned.

 However, what you call "groupthink" (which I find rude, tbh), is an effort
 to bring de facto PHP best practices to WordPress, trying to get it out of
 the "legacy software" drawer it keeps getting put into more and more. I
 think that all the people contributing on Trac are interested in seeing a
 bright future for WordPress, so it hurts to have it be too tightly stuck
 in the past.

 > 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.

 If you use a tried and tested autoloader, there's no need to step through
 it with XDEBUG, so I don't see why this would be relevant.

 > 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.

 '''If it is problematic to apply (de-facto) best practices to a project,
 chances are the best practices are not a fault.''' This probably just
 points to an inherent design flaw that should be addressed.

 > [...] WPLib Box [...]

 There are lots of solutions available for something like this, all with
 different kinds of merits. I don't think this ticket is the best place to
 discuss these, though.

 > '''My preference would be that WordPress 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.

 The Composer autoloader is generated by an `AutoloadGenerator` ... which
 can be completely customized. If there is a concensus on how the resulting
 autoloader should look, just let me know and I'll quickly code up a
 generator for that particular format. Composer is flexible enough to
 support ANY resulting classloader format, not just the one shipped by
 default.

 > 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.

 The optimization is certainly something that needs to be done, but
 premature optimization at this point is completely useless (and counter-
 productive), as we're just figuring out how to autoload at all without
 breaking stuff at this point.

 That being said, the Composer autoloader is already tightly optimized in a
 proven way, and it is difficult to get any improvements over it with
 anything but very simple scenarios.

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

 While I agree that using class names instead of arbitrary filenames, this
 discussion is not relevant for the autoloader and should be done in the
 context of the WP Coding Standards efforts.

 > 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.

 The whole point of a class map autoloader is to associate arbitrary
 filenames with class names. If you can determine one from the other, you
 don't need a class map. You can just use a PSR-0 or PSR-4 autoloader.

 > > 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.

 I fail to see how that would be preferable to have a mature, 5-year-tested
 class map builder that is used by the rest of the PHP world.

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