[wp-trac] [WordPress Trac] #36335: Next generation: core autoloader proposal
noreply at wordpress.org
Thu Mar 31 17:30:01 UTC 2016
#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
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
However, I think to make core actually "autoloadable" is a priority in
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
More information about the wp-trac