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

 > I think whether we adopt Composer usage or not isn't hugely relevant to
 this conversation; while it has the ability to solve some of the problems
 here, it's also a huge architectural change to get it to the point where
 it would make sense. Let's discuss this on a new ticket rather than here.

 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.

 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).
 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 discussion so far has been to decide whether to use a custom
 implementation to allow adding namespaces at runtime so that plugins and
 themes can also use it from the get-go (@dnaber's initial proposal), or to
 stick with autoloading for Core for now until we're more confident in what
 we're doing (and have namespaces!) by using Composer as a build tool to
 generate the autoloading.

 @rmccue The polyfill is a good idea (for as long as introducing deprecated
 code is preferable to bumping the PHP version), 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 completely agree to @atimmer's entire comment.

 So, I would recommend discussing the polyfill and the autoloader
 implementation as two separate issues, and for the autoloader
 implementation I don't see any particular advantage (but some
 disadvantages) to @rmccue's proposal over just having it be automatically
 generated through Composer. If all we want is a class map for Core,
 there's already a tool for that.

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