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

 Although I would really love to have an autoloader be centrally available
 within WordPress, I fear that the current proposal will cause more issues
 than it solves.

 * Autoloading large-scale projects (that depend on a lot of external
 resources like libraries/plugins/themes) goes hand-in-hand with
 namespaces. Without namespaces, you are guaranteed to have conflicts.

 * Usage of an autoloader will only start to provide tangible benefits if
 it is combined with a clear OOP architecture that makes use of dependency
 injection and lazy-loading. Without these, you will probably end up still
 including everything (to avoid breaking stuff), just with a lot of
 overhead.

 * Assuming that one of the long-term goals for WordPress is to be a
 prominent citizen within the PHP world, building our own autoloader
 instead of using the one from Composer (that pretty much ''every'' other
 recent PHP project uses) will just add another roadblock for developer on-
 boarding, and doesn't allow us to reuse the huge amounts of work that have
 gone into Composer's implementation as well as optimization (which
 contains a lot of code to make the autoloader efficient & scalable for
 production).

 * When talking about eventually adding dependency/package management in
 the future, it should be a given that interoperability is critical. This
 makes building our own autoloader problematic again.

 I would recommend just adding a `composer.json` for now and using this to
 work on making WP's components autoloadable in the first place. Composer
 can generate the optimized class maps, and it can even provide a PHP5.2
 compatible autoloader. This avoids "reinventing the wheel from the past".
 Composer itself would only be a development requirement to make changes in
 Core, so the fact that it requires PHP5.3.2 to rebuild the classmaps
 should not be an issue.

 Making everything properly autoloadable is probably enough work for one or
 the other release as it stands.

 Once this work is done, chances are that we can make the switch to PHP5.3,
 and make the central (Composer) autoloader available to plugins & themes.
 In the mean time, we won't introduce new issues through an autoloader that
 won't provide the benefits that we hope for.

 This would also provide the additional benefit that, once the
 `composer.json` has the correct autoloading settings and the WP classes
 are properly autoloadable, you can very easily efficiently reuse this data
 in a composerized WP stack.

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