[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:  Future Release
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+-----------------------------

Comment (by schlessera):

 > Going from no autoloading to some is a huge step; how we actually create
 the autoloader(s) is a bit more of an implementation detail. I don't have
 a huge issue with using Composer to generate a classmap, but I want us to
 take small steps to ensure we get something in here. :)
 Yes, totally agree. But adding Composer autoloading is adding 1 tiny file
 (`composer.json`) and adding 1 line of PHP to one of the bootstrapping
 files (like `wp-load.php`): `require_once( ABSPATH .
 '/vendor/autoload_52.php' );`. This results in a working autoloader that
 keeps everything up-to-date as Core classes are changed.

 Also agree with my two PHP observations being no real issues, just added
 them for reference.

 > I've split the polyfill into a separate ticket at #36926, as we can ship
 it independently of the autoloader implementation.
 Yes, one should not block the other.

 >I actually want to remove the entire classmap code from core; the only
 reason my code includes this is because we currently don't have a clean,
 standardised mapping (whether PSR-0, PSR-4, or WP-style) for various
 legacy reasons. Ideally, the classmap will disappear entirely from core.
 >That's not to say I don't like classmaps, but I want it to primarily be a
 performance optimisation built on top of a clean system, rather than the
 current hacky approach that doesn't really improve how terrible the system
 in WP is right now. Independently of autoloading or anything, the current
 approach makes it hard to actually work with core.
 >So tl;dr: I'm in favour of automated classmap generation once we have a
 stable class -> file mapping system.
 I just referenced the classmap as this is what you had submitted. Composer
 can actually work with any imaginable way of locating the classes,
 including a classmap or PSR-4.
 The classmap is more of an intermediary step to have autoloading work
 while we don't have a standardized file/naming structure yet. Composer
 could take us all the way from first temporary/intermediary steps to final
 implementation in an automated, robust way.
 The nice thing about the classmap though, is that it can make autoloading
 work right away, letting us remove the majority of the `require`
 statements, and still let us rearrange files in an ongoing process.

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