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

 Following up since it has been 4 days since last post and no comments on
 what was previously a very active ticket ''(and it is Friday evening so I
 have time to!)''

 Thus far the big debate has been over ''"use a composer autoloader"'' vs.
 ''"use an autoloader optimized for WP"'' and that has been contentious. So
 let me suggest a different first step that I think that maybe all of us
 will see the need for ''(or at least all of us that would like to see an
 autoloader built in to WP core.)''

 '''Proposal: First discuss making core files autoloadable, and then divide
 and conquer to analyze the core files in need of changes?'''  Some files
 will be very easy to make autoloadable whereas others will be require more
 finesse. Because without making core files autoloadable the ''"which
 autoloader"'' question is moot.  Why not go ahead and prepare patches to
 apply that are easy to apply and that we know will not break anything?

 1. If we use a classmap autoloader we can have great flexibility in how we
 organize files. In my prior patch I created two locations for autoload
 files: `wp-admin/autoload` and `wp-includes/autoload`, for hopefully
 obvious reasons. However if we want to plan for the potential to use a
 Composer autoloader '''so that we can move this ticket forward''' then we
 will need to have one root location for autoload files. This could be `wp-
 autoload` but based on some prior related comments on this thread I think
 some people might object to a new directory in the root?  Putting it in
 `wp-includes/autoload` and then moving all files from within `wp-admin`
 that need to be autoloaded just feels wrong.  '''So, can we discuss this
 point:  What should the autoloader's root directory be?'''   In the
 interim I am going to use `wp-autoloader` but that will be trivially easy
 to change if we so desire. ''(if we do not need to leave the option open
 to use a Composer autoloader then we can easily just use `wp-
 admin/autoload` and `wp-includes/autoload`.)

 2. No matter which autoloader we ultimately choose the autoloader must
 derive the file name from the class name, so I propose we change the file
 naming convention for autoloaded classes to be their classname, e.g. `wp-
 autoloader/WP_Query.php` vs. the current `wp-includes/query.php`.  '''Can
 we get a thumbs-up or a thumbs-down for this approach?''' And if a thumbs-
 down it will help if you provide a detailed reason why not along with a
 better alternate proposal including the benefits for the alternate
 approach?

 I'll continue with details related to dividing an conquering on another
 ticket so these two questions do not get lost.

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