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

 I want to add some clarifications to some of what's been written before.

 First of all, I want to make it clear that I am not against the goal of
 having a '''public API''' for letting plugins & themes '''register
 autoloader mappings at runtime'''. However, I see this as the '''last
 step''' in a long term effort, not the '''first step'''.

 I think that, starting out with the public API spells disaster while we
 still have the following issues:
 1. we are still bound to PHP 5.2 compatibility ('''no namespaces''');
 2. we have '''no clear naming rules''' for some of the elements we are
 trying to write the API for;
 3. Core is in a state where it does '''not know what is needed from this
 API''', and '''couldn't fulfil its requirements'''.

 The "just use Composer" approach does not preclude adding a public API at
 some point that lets plugins & themes add autoloader mappings at runtime.
 However, it '''postpones deciding on the final structure of this API'''
 until a point in time where the above three issues have been solved.
 Composer is just a fast way to be able to attack these systematically.

 Anther thing to consider is that the one true benefit that an autoloader
 brings to the table that you can't easily have without is the way you can
 "just use" libraries. You don't have to call any bootstrapping code that
 will `include` lots of stuff, you don't have to `include` yourself, you
 don't have to check if an external class exists first. If you now start
 with a custom autoloader specific to WordPress Core, you might be able to
 autoload a plugin's classes without `include`s (you saved a few lines of
 typing), but you blocked access to that biggest benefit of an autoloader.
 Let's be honest: all the great modern PHP libraries can saves us hours and
 days of custom development when working on a larger project '''will not be
 rewritten''' to make them work with a WP-specific autoloader! So each of
 them will need special forks/bridges/adapters to use within WordPress.
 That's not really progress, if you ask me...

 > 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.
 Yes, they could start using the autoloader. My personal belief is that
 this will lead to loads of breaking code further down the line, as we will
 have lots of plugins & themes that don't use namespaces and will produce
 all sorts of conflicts. We will then end up with thousands of problematic
 plugins, and no way to deal with the conflicts they produced. What's
 worse, with the backwards compatibility policy of WordPress, we would not
 even be able to make drastic changes to the autoloader itself to remedy
 that situation.

 Presence of an autoloader makes naming conflicts worse, as they may not be
 immediately obvious. That's why I think namespaces are an absolute must
 when using an autoloader.

 > we shouldn't allow for registration of custom autoload rules
 Agree, PSR-4/WP-? & classmaps should be more than enough.

 > The biggest problem with using Composer as a solution for WP is the
 sheer number of sites and servers that will not have it installed.
 Therefore the only viable option IMHO is to bake an autoloader into core.
 That's not an issue. For the approach I recommended above, Composer would
 only be used at development time for as long as WP stays at PHP 5.2. After
 that, you can just as well include Composer with WordPress, it does not
 need to be installed globally. So, if you want to bake in an autoloader
 into WordPress Core, why not just use the one that the rest of the PHP
 world uses?

 > "Hey everyone... we just took a giant step forward into the future...
 and adopted a deprecated system for autoloading!!!"
 I might be wrong, but I assume that, when talking about an autoloader,
 you'll get a similar reaction for "''not using namespaces''", as well as
 for "''not using Composer''". As far as I am concerned, the simple fact of
 starting to build a ''custom'' autoloader is "''reinventing the wheel from
 the past''" as I wrote further above.

 > 1. Build a list of classes
 > 2. Map list of classes to file names
 > 3. Fix file names + fix includes that break in this step
 > 4. Break out classes when there is more than one class in a file + fix
 includes … again
 > 5. Think about autoloading … again (but now with a strong base)
 Yes, I also recommend an approach similar to this. In addition to that, if
 we're using a `composer.json` for the autoloading from the beginning, we
 have an easy way to test and immediately use the changes, and "''fixing
 includes''" would be replaced by "''add to composer.json''".

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