[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:221 schlessera]:
 > The difference in memory usage probably comes from the fact that your
 approach has relative paths in the classmap, and the Composer one has
 absolute paths in the classmap. Again, this can be changed into whatever
 we want for both, so that point is moot as well.

 The key point I was trying to convey is that autoloading has a lower
 memory footprint than what is currently in core, no matter which
 autoloader we use. After all, ~1% is within the margin of error.

 > A note regarding your comparison: the one currently merged into the
 feature project GitHub repo has excluded most of the third-party/legacy
 classes for now:
 https://github.com/staylor/develop.wordpress/blob/autoloader/src/composer.json#L49-L68

 Similarly we can optimize the custom autoloader by including these classes
 to exclude [https://github.com/staylor/develop.wordpress/pull/2/files
 #diff-aa79250a91f72b52e20d458064bbce13R15 here] or we could easily add an
 `omit_files()` method to omit them by filename.  And I would like to get
 rid of the filepaths from the classmap entirely, but that would require
 moving the classes to files with new names in a few known directories.
 Together that would lower the memory footprint even more.

 BTW, having files listed in an autoloader that do not ever need to be
 loaded does not break anything -- as you know -- it only takes up memory.

 > And I would once again make you aware that you're now slowly building,
 feature-for-feature, a replica of the Composer Generator, but without the
 unit tests, without the community and maturity, and without the
 standardized configuration.

 And without the bulk and overhead of handling all use-cases.

 We do not need to handle all use-cases -- constraints can be beneficial,
 especially to enable simplification -- so we only need to handle the small
 subset that applies to core.

 Further it also means we do not have to deal with Composer making breaking
 changes in the future which anyone on core who has dealt with breaking
 changes from jQuery can almost certainly attest to.

 > This last point is very important, as it allows to reconcile several
 autoloaders into a single coherent, optimized autoloader. I still fail to
 see what the exact '''advantage''' is of reinventing the wheel...

 If Composer were the right tool for the job, I might agree, ignoring the
 potential for future breaking changes.  But Composer is not the right tool
 for WordPress as [https://wptavern.com/i-love-composer-i-love-wordpress-
 but-i-object-to-a-marriage several people]
 [https://github.com/wecodemore/wpstarter/issues/55#issuecomment-248620966
 have recently] [http://blog.wppusher.com/a-warning-about-using-composer-
 with-wordpress/ said].

 And if the Composer autoloader can end up being written to do everything
 exactly as the custom autoloader -- with the same optimizations we are
 capable of with the custom autoloader -- than what actual benefit is there
 to using the Composer autoloader other than introducing a lot more code to
 core and adding an external dependency? ''(Yeah, I know. Those are not
 benefits.)'' I mean, I thought the argument for it was that it was already
 written?

 Composer is a square peg and WordPress has a round hole.  It is a really,
 really nice square peg, but square pegs and round holes don't mix.

 Replying to [comment:222 schlessera]:
 > @wonderboymusic: Please enable Issues on the Feature Project's GitHub
 repo so we can have a more structured discussion.

 Yes. Please!

 ''(P.S. I will be so glad when the core committers makes a decision on
 this -- no matter what the outcome -- so that this pissing match will
 finally stop.)''

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