[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:202 TJNowell]:
 > I'm not a fan of moving the files at this stage,

 How are we going to validate, test and benchmark without doing do?

 > and it might break existing code that includes certain files directly

 IMO that is why we would run it through the WordPress test suite.

 > Generating the classmap should also be a build step, adding constants
 for runtime seems counterproductive.

 Agreed on the first part, the second part would not be for core but
 instead for website projects for people who do not use build tools.  IOW,
 98% of people who set up WordPress sites.  :-D

 Currently the classmap gets generated from classes in `/wp-admin/` and
 `/wp-includes/` and stores the classmap as `/wp-classmap.php`.

 For the generation for those in the wild it could generate a ''user''
 class map for classes in `/wp-content/` and store the result in `/wp-
 content/classmap.php`.

 > I'm also concerned that the generation code relies on global variables
 and isn't very testable, it wouldn't be possible to write an easy unit
 test.

 The classmap generator itself is proof-of-concept written as quickly as
 possible.  Please don't get tripped up and assume the proof-of-concept is
 meant to be production ready code.

 That said, the classmap generator is really simple so refactoring it to
 remove globals and make it testable would not be a big job.

 > I'm also concerned by the new top level files, we should keep the root
 clean and adding new top level files is going to garner some flack, I
 would move those to wp-includes

 Yeah, nothing about this proof-of-concept requires top-level files, that
 was just the arbitrary choice because it seemed the most logical given it
 represented files from both `/wp-admin/` and `/wp-includes/`.

 > Regarding performance, even crude benchmarks would be helpful.

 Definitely.

 > Without optimisations an autoloader would make WP slower due to the
 larger number of files...

 Honestly, my seat-of-the-pants for loading pages in the admin was
 noticeably faster.  And given the architecture I chose there is very
 little overhead in the autoloader so if it loads 1/2 as many files that
 would be why.

 But I know perceptions are subjective so I am really anxious for some real
 benchmarks. I have never implemented benchmarks for a  WordPress site
 before and don't really have the time to research how to do it so I am
 hoping someone else can step up and try this.

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