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

 @MikeSchinkel : I think you're completely derailing this ticket. If you
 want to discuss changing the WordPress Coding Style, or the WordPress
 folder layout, please do so in a new ticket.

 Reading through the last handful of comments, it seems like I still wasn't
 able to fully communicate what Composer brings to the table.

 When going with Composer, we don't buy into the Composer Autoloader, as
 the standard Composer Autoloader is unusable for WordPress. What we want
 is the '''Composer Autoloader Generator'''. We want to add another tool to
 the build-time chain that let's us parse our current code base and create
 an autoloader adapted to our needs. The Composer Autoloader Generator
 parses the actual PHP in the files to discover the classes. It doesn't
 care about the filenames, it manages several classes in one file, etc...

 The resulting autoloader that is built from that parse step can be
 completely customized to whatever we think is best. We can include any
 special WP cases, we can optimizie how we want, etc...

 So, when you state above:
 > but this patch will become stale pretty quickly so if we want to move
 forward with this we would be best to make a decision sooner than later
 otherwise most of the work I did will have to be redone again on a future
 version of WordPress.

 ...this is the exact reason why I initially proposed to use Composer as a
 build-time tool in the first place. '''We will not optimize the WordPress
 Core in one or two releases''', and I'm surprised you would think such a
 thing to be feasible.

 The goal with using Composer Autoloader Generator as a build-time tool was
 always to just have a very quick, first step to make autoloading even
 possible, to get to the real problem: needing to shuffle classes, files
 and folders around for several releases to optimize the Core for
 autoloading. In the meantime, with every change, a simple re-run of the
 Grunt build will fix whatever you broke in the autoloader. And I've said
 it before: the actual autoloader that is generated by Composer can be
 freely adapted.

 So, that being said, I would be relieved if we could stop talking about
 how optimized a specific autoloader implementation is, as that is
 completely besides the point at this time. Also, we don't need to rename
 or move files at this point, Composer will just take care of it. The only
 thing that needs to be done is to remove global functions from files we
 want to have autoloaded, which has already ben done in the initial patch
 by @wonderboymusic and can currently be seen in the `autoloader` branch on
 [https://github.com/staylor/develop.wordpress/tree/autoloader].

 @MikeSchinkel the way I see it, the solution you propose:
 * eliminates the advantage that initially brought us to Composer (hence
 your need to rename files and move stuff around),
 * eliminates all other advantages that Composer would add in the future,
 * only seemingly adds one perceived advantage of its own (tightly
 optimized custom autoloader), which is not really an advantage, because
 you can generate this exact same autoloader with Composer Autoloader
 Generator.

 Unless I'm missing something crucial, and don't see in what ways this
 solution would be preferable.

 @TJNowell If anyone wants to play around with benchmarks, please go ahead.
 I personally will not waste time with benchmarks right now. If the goal is
 to see what autoloader '''implementation''' is faster, then this has
 nothing to do with Composer/no-Composer. And if the goal is to see whether
 an autoloader even makes sense in the first place, then I'm baffled, and
 must admit that we will never find out, because first of all the benefits
 are not only about performance, and secondly, we would need to implement
 it and optimize Core for it first to get proof. So, in essence we're
 trying to benchmark the chicken and egg problem.

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