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

 > Not true. From @schlessera's own comments on his proposal we are
 discussing:

 That makes no sense, that's not how Composer works, perhaps you've
 misunderstood use of composer for inclusion of composers entire codebase,
 something that is not being suggested. The language could be misleading
 for somebody without knowledge of how Composer is used.

 > Composer champions an approach that places all autoloadable classes into
 a /vendor/ directory and then maps to the file based on class names.

 These are the PSR standards, we don't use those, and we don't need to,
 this ticket discusses classmaps, and the classmap autoloader is what's
 under discussion. You do not need to put classes in the vendor folder to
 autoload them, and you do not need to follow PSR conventions.

 > Then within each of /plugins and /mu-plugins there can be a potentially
 unlimited number of locations to look for classes to autoload.

 This is the core autoloader, mu-plugins and plugins are not core, plugin
 developers can and do handle loading of files themselves, this is a
 separate topic.

 > And having core use its own classmap autoloader does not preclude anyone
 from using Composer's autoloader for PSR0/4 libraries.

 We're not using PSR0/4, neither is it necessary to use such PSR0/4

 > Why include (some of) these 10 files when you really only need two
 trivial files? One containing a trivially simple autoloader and another
 file containing a trivially simple classmap?

 Some plugin authors may wish to use PSR0/4, and it would prevent
 compatibility problems if a plugin required a library that used such
 standards. While core doesn't use it, we shouldn't prevent it, or cause
 issues elsewhere. Or we could generate our own custom autoloader. For
 example [https://github.com/rmccue/Requests/blob/master/composer.json
 rmccue/requests]

 > In addition core could load core's classmap and then run hooks to allow
 plugins and themes to contribute their own classmaps.

 I agree, the main ClassLoader object has methods for adding classmaps and
 other information about where to load things, it should be passed through
 a filter, if only for debugging purposes

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