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

 Regarding the difficulties with the build-time move from `src/*` paths to
 final paths, there is an alternative solution:
 We could use a custom autoloader generator that does not use relative
 paths, but rather paths based on a set constant, like `ABSPATH`. This
 would remove any assumptions about the build steps changing the folder
 hierarchy, as long as the surrounding code always properly defines this
 constant.

 In reply to @azaozz :
 > Classes autoloading is very nice for OOP apps. However WordPress is not
 an OOP app. It's true, there are about 200 classes. Many of them are just
 containers for namespacing the functions inside. These are not meant to be
 extended or used in any OOP way.

 Autoloading has several benefits out of the box, even with a more
 procedural codebase like WordPress:

 * Instead of loading everything that might be used within a given code
 path (which often ends up being almost the entire code base), you
 effectively only load and process the exact amount of code you need, when
 you need it. This will most probably reduce (only benchmarks can tell for
 sure) memory consumption and processor work, and result in faster load
 times. I expect that especially AJAX calls (which often only do a small
 task and immediately die) to see drastic improvements, once the move to
 autoloading is completed.

 * The code does not need to know the path to classes anymore. This removes
 a lot of hard-coded strings and assumptions, and makes moving and
 reorganizing the code a breeze. After work on the autoloader is completed,
 moving files around would not be a breaking change anymore, as only the
 autoloader generator should need to know about their location in the first
 place.

 * Usage of an autoloader makes a lot of "timing" related bugs obvious,
 where code was only working "by chance" because the exact execution path
 of a section of code was necessary to have the correct files loaded when
 they were used.

 * An autoloader makes the inclusion of third-party libraries (of which
 there are a number already included within WP Core) much easier, if each
 of the libraries just knows how to include its own autoloadable assets.
 This way, your code does not need to know anything about the actual file
 layout of a third-party library, it just needs to know what initial
 class/function to use.

 * The order of loading becomes irrelevant, as everything is loaded at the
 point where it is required.

 Not all of these benefits can be completely delivered with this first
 iteration, because the code base is not yet fully adapted to make the best
 use of an autoloader. But already having an autoloader is a first
 necessary step, and it makes a lot of other changes to the code much
 easier.

 > There are also about 4750 "loose" functions. What does autoloading do
 for them?

 Not much, indeed. Their files can be added to the Composer autoloader, but
 this will just immediately `include` then when the autoloader is loaded.

 However, this does not in any way reduce the other benefits that the
 autoloader provides. The fact that one half of the code base will not
 become faster and lighter does not make it useless to have the other half
 become faster and lighter. And I think it is obvious that there's a clear
 trend towards OOP with the more recent code additions, so the benefits
 will only grow with time.

 > Another thing that needs clarification: if we have autoloading, would a
 plugin be able to stop some of the core classes from loading, noop or
 replace them etc. That would be a backwards compatibility disaster down
 the road :)

 Yes, a plugin could potentially do this if it would `require` a class with
 the same name before it was loaded through the autoloader. However, I
 can't see why a plugin would want to do that, and it would probably break
 half of the time, because autoloading means there's no set point in time
 where you know the class was or wasn't loaded any more. Also, I think
 there's a number of classes and functions that contain a `class_exists()`
 check before being loaded, so these could just as easily be replaced by a
 plugin version.

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