[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:  2nd-opinion      |     Focuses:
-----------------------------+-----------------------------

Comment (by schlessera):

 Thanks for updating the ticket with our discussion, @rmccue.

 I'd like to add some details to the summary above.

 Additional arguments for Composer:

 * Composer can just as well generate any autoloader from the first
 temporary classmaps to the final structured layout using whatever rules we
 come up with, so it provides the entire update path from first tests to
 final implementation.
 * Composer is very mature, it has been tested and optimized (and used at
 the largest scales) for 5 years.

 Additional arguments against @rmccue 's proposal specifically, but also
 against any custom implementation in general:

 * A custom implementation again creates some distance between WordPress
 and the larger PHP ecosystem.
 * A custom implementation will probably result in a custom autoloader to
 be used for plugins & themes later on as well, which will eventually cause
 all sorts of issues with the now de facto standard autoloader already used
 in a lot of plugins (Composer).
 * Planning a custom implementation while we still don't have namespaces
 will result in an implementation that will be too easy to break (naming
 conflicts).

 Observations regarding @rmccue 's responses to these objections:

 > Adding Composer is an entirely separate issue [...]
 I repeat again that we are not talking about using Composer for dependency
 management, we are talking about using Composer's autoloader generation as
 a build-time tool. We already have `npm` (the `node-js` command line build
 tool) as a build-time tool within Core, so why should it not be obvious to
 also have `Composer` ( the `php` command line build tool) as a build-time
 tool within Core?

 > Maintaining our own autoloaders is not unreasonable.
 No, but neither is there any advantage to be had through that additional
 manual effort. It is neither sensible, nor productive.

 > The classmap is temporary [...]
 But the code also includes interfaces & classes. Although they are meant
 to be temporary, we all know how temporary stuff is dealt with in a
 codebase that makes backwards-compatibility an absolute priority.
 I would guess that it will just be the too-briefly-planned start of an
 elaborate coding effort to create a WordPress autoloader that can support
 all edge cases that the rest of the codebase can come up with.

 I agree that there's two fundamentally different approaches being
 discussed here, and while I understand the reasons why @rmccue would like
 to proceed how he proposed, I still think this to be an approach we'll
 regret in the future, adding one or more example to the list of problems
 where WordPress didn't care to learn from the mistakes of other platforms.

 So, for what it's worth, my position is to either go with Composer as a
 build-time tool or to prefer not to have an autoloader in Core at all
 until conditions have changed enough to rediscuss (namespaces!).

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