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

 Replying to [comment:37 schlessera]:
 > We're not talking about using Composer for dependency management here,
 but rather using Composer as a build tool to generate an autoloader
 through the de factor standard PHP autoloader generator, instead of
 rolling our own implementation, so I would say it is highly relevant.

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

 > I won't discuss any of the code in detail, as I think we're still not
 sure about some principalities here. I just want to note that, regarding
 the polyfill, you need to keep in mind that `__autoload()` will probably
 throw a notice with PHP 7.1
 (https://wiki.php.net/rfc/deprecations_php_7_1).

 Won't be an issue, as the whole file will only be loaded for 5.2-without-
 SPL.

 > Also, I think the polyfill should not throw exceptions, as it will only
 be used with 5.2, and prior to 5.3 these are not able to be caught and
 will throw fatal errors (see note in
 http://php.net/manual/en/language.oop5.autoload.php).

 The autoloader itself doesn't throw exceptions, just the autoloader
 registration code (`spl_autoload_register`); it's up to the actual
 autoloader implementations themselves to decide whether the compatibility
 here matters or not.

 > @rmccue The polyfill is a good idea (for as long as introducing
 deprecated code is preferable to bumping the PHP version)

 The PHP version decision isn't mine to make, so I'd prefer to avoid it. :)
 I've split the polyfill into a separate ticket at #36926, as we can ship
 it independently of the autoloader implementation.

 > but the rest of your proposal now unites only the drawbacks of both of
 these methods, by providing a build-time-only, Core-only autoloader, but
 not using the standard, mature, tested, highly optimized one from
 Composer. If we only want to have a classmap for Core for now, why not
 just use that 1 Composer line and have it generate something we can rely
 upon without much further thought, and know that we're not locking
 ourselves down for the future?

 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. Let's stick to small patches that we
 can ship quickly rather than trying to reform all of WP at once.

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