[wp-trac] [WordPress Trac] #36335: Next generation: core autoloader proposal
WordPress Trac
noreply at wordpress.org
Sat Sep 24 05:42:17 UTC 2016
#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
More information about the wp-trac
mailing list