[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 giuseppe.mazzapica):

 > Anyway, the major benefit of having an autoloader would be having a
 consistent way for plugin authors and later talking about
 dependency/package management. Because we're runing into a big issue with
 inconsistent packages, when plugin authors keep on using composer and ship
 their dependencies with their plugins. And they will.

 Autoloader does not resolve the dependency/package management issue.
 Actually, if autoloader is shared there are chances it causes even more
 issues.

 To give you an example, let's assume I have a plugin which has a
 dependency to `AwesomeLibrary` in version '''1'''. And another plugin that
 uses same library, but in version '''2'''.

 If we have a shared autoloader, both plugins will somehow "register" a
 rule in the shared autoloader to load the `AwesomeLibrary` class.

 Assuming that the class is named in the same way in both versions (a very
 reasonable assumption) which version of the file the autoloader have to
 load when `new AwesomeLibrary()` is encountered in code?

 This just to demonstrate that autoloader and dependencies are related
 issues, but solving one does not necessarily solve (nor necessarily help
 in solving) the other.

 To bring you a real world example, Composer autoloader works very well as
 a shared autoloader when Composer is used to manage the entire website,
 because it has control on all the dependencies and so there's the warranty
 only one version of each package is installed. In fact, it fails miserably
 when different plugins ship different version of same library.

 Moreover, a dependency/package management tool does not ''require'' an
 autoloader: it's a convenience not a requirement.

 For these reasons I think that having an autoloader would not facilitate
 the dependency/package management discussion that much.

 That said, I think an autoloader for core is a nice thing and pretty easy
 to realize (surely easier than dependency/package management by far) and
 if we focus on core autoloader there might be chance it will be done, as
 some point.

 However, I think to make core actually "autoloadable" is a priority in
 that direction.

 For example, consider the issue of files containing more classes. There
 are two ways to solve it: 1) split the files; 2) write a complex
 implementation capable to work in those cases.

 If you go with the latter, and at some later point the file are split, you
 wasted time and effort on create an unnecessary complex proof of concept
 implementation. Wouldn't been better to start working on a proof of
 concept ''after'' files were split or after the decision to not split the
 file was taken?

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