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

 Replying to [comment:207 schlessera]:
 > 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...

 '''Generating classmaps is trivial.'''  My ~50 line classmap generator
 proof-of-concept that was included in my huge patch illustrates this.

 So we can please refrain from using ''"Composer can generate a classmap"''
 as a reason to use Compser and instead move on to focus on any other
 potential benefits Composer can provide that I am evidently missing?

 Wait. Strike that.  ''Can we just table Composer-or-Not for now and work
 on moving anything else can we move foward?'''

 > 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...

 But not without having to using `is_file()` a lot. Or are you suggesting
 that we go ahead and accept that it will '''always''' be classmap based?

 > ...this is the exact reason why I initially proposed to use Composer as
 a build-time tool in the first place.

 My statement about staleness is now moot since nobody has taken any action
 on it.  So I have decide to move forward with a much more incremental
 approach, hence my numerous comments and additional planned comments
 today.

 Instead I plan on offering patches that either won't be stale or will be
 generated via a shell script.

 > '''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.

 And I am surprised that you think it is such an overwhelming job. Sure, to
 get it to 100% will take a while.  But based on the analysis I have been
 doing '''I see no reason why we can't get to 80% in short order.'''  The
 only thing holding us back is will and needless bikeshedding.

 > 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.

 So that seems to me to be a very small benefit for all the intensity of
 debate.  Generating a classmap is almost trivial, as I have demonstrated.

  > 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.

 But the autoloader generated by Composer will need to be modified as as
 Ryan McCue
 [https://core.trac.wordpress.org/ticket/36335?replyto=207#comment:180
 points out].  Thus we really get no ''"it just works"'' benefit from using
 the Composer autoloader and we get the overhead that it generates too.

 > 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.

 Then why don't we just debate the specific pros and cons of naming
 conventions -- as I was proposing we debate -- instead of getting back on
 the Composer soapbox right now?

 One of the benefits of having files named for their class is that it makes
 it performant to load the classmap dynamically, as would likely be the
 case for files in `/wp-content/`.  Being able to scan a directory and grab
 the filenames as classnames means their is no potential breaking ambiguity
 in the conversion of the classname.

 That said, I don't consider the file naming part critical, just a nice-to-
 have I would prefer that we adopt.

 '''What I do consider critical is that we stop having circular debates and
 move things forward''' by finding things we can work on that do not
 require resolving the Composer debate, and that get us closer to seeing an
 autoloader included, no matter which autoloader it is.

 > https://github.com/staylor/develop.wordpress/tree/autoloader

 This is news to me, thanks.

 > * eliminates the advantage that initially brought us to Composer (hence
 your need to rename files and move stuff around),

 I think you keep saying this has an advantage but from my vista is seems
 all those proposed advantages have turned out to not be real advantages.
 If the main benefit is to save time then in the time we've debated this we
 could do that work you are trying to bypass three times over, and do a
 much better job.

 '''Why debate a one-time process at the level of a fundamental
 architecture decision?'''

 > * eliminates all other advantages that Composer would add in the future,

 Which is why I said '''let up bypass this Composer-or-Not and instead work
 on making core classes autoloadable'''.

 But since you bring it up again, as Ryan said I think this is a solution
 looking for a problem. So please detail your expected advantanges as they
 related to WordPress. This far all I have read is that Composer's
 advantages are ''"because it is standard"'' and ''"using is is a best
 practice"'', but I have not read about any specific tangible benefits that
 using Composer with WordPress core would provide WordPress.

 No, wait.  That will only delay moving things forward.  But please do give
 those explanation later when the Composer-or-Not decision is back on the
 table.


 > * 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.

 But even if we could, why work with a tool that writes code -- a tool that
 you have to work to tweak -- when the code is trivial to write by hand?

 As an aside, you cannot generate this '''exact same''' autoloader with
 Composer.  But I digress.

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

 '''And I don't see how Composer is preferable either, so let us first
 focus on what we can move forward, okay?'''

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