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

 To be honest, I would've expected at least ''some'' response to the last
 comment(s).
 But maybe other people have the same problems I have (or had)...?

 I really do like the idea to use Composer's autoloader. And at the same
 time I don't like it (for now?).

 Just so this has been said: we did '''not''' propose a custom autoloader
 (no matter if the one over at [https://github.com/inpsyde/wordpress-core-
 autoloader the repository at Inpsyde's], or another one) because we would
 like to '''write''' an autoloader. The one and only reason is to '''use'''
 a single central autoloader.

 As mentioned numerous times, the current state of Core WordPress's
 codebase does not play nicely with a modern autoloader. So there's (a lot
 of) work to do, and we all know that.
 When David created this ticket, the plan was not to only work on a
 functional autoloader alone. In parallel, one could also start with some
 of the changes that need to be done with respect to WordPress itself.
 Our idea was (and hopefully, it still is) to implement a functional
 autoloader (which we started in the GitHub repository linked above), and
 then integrate it in some WordPress fork. To demonstrate its usage.

 The main, and in my opinion, very important difference between this
 approach and the one proposed by @schlessera is: '''who''' can make use of
 the autoloader '''when'''.
 With ''our'' approach, plugins and themes could start using the autoloader
 with WordPress 4.6 already, for instance. Changes at Core WordPress could
 then be made step by step, when the time is right for each of these steps.

 The one problem with these changes is ... that there are a lot of
 individual problems. ;)
 Changes only can be made in a granular fashion. One would need to agree on
 a consistent naming scheme for classes and interfaces (okay, okay, there
 are none—yet!). Moving parts from one file to another makes it hard for
 anyone working on patches for that file. Then, some day, we maybe have
 namespaces. All this makes preparing (and, later on, adapting) WordPress a
 tedious task.

 If the long-term goal is to eventually ship an autoloader that '''works'''
 like the one of Composer (and maybe at some point in time we actually use
 Composer in general), we shouldn't allow for registration of custom
 autoload rules (as we called the classes implementing the individual
 autoloading logic). Instead, we should only offer a small set of
 autoloading ''ways'', so each plugin or theme author can choose what works
 (best) for them. PSR-0, PSR-4, a classmap (because the plugin/theme
 doesn't follow PSR-whatsoever), ...
 What we would gain here is the ability to dynamically register with the
 autoloader—opposed to only have WordPress (partially!) use the
 autoloader.

 I'm really interested in your opinions here.

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