[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 don't get it. Why they would have to be rewritten? Most of them are
 PSR-4 compatible, so you would just have to register their
 directories/namespaces to the autoloader.
 No, unfortunately not. The nice thing about a package manager (which
 pretty much all of these libraries now use), is that it does not only take
 care of the direct dependencies, but also of the dependencies'
 dependencies, recursively. This is was encourages developers to reuse
 existing code by just pulling it in, instead of copying it somewhere.

 So, if you don't use a system like Composer, you will not only have to
 register that library's namespace, but also the namespace of all of its
 dependencies at each level and sublevel. Composer's main work is done
 recursively, which is a HUGE benefit.

 > Disagree. In my eyes, that would be a violation of the open/closed
 principle. Psr-4 is sure used by everyone out there but in fact it's not
 an optimal solution as it is case-sensitive (I mentioned this earlier). I
 wouldn't like to restrict developers in this way.

 I was not talking about restricting the code (implementations are details
 to be discussed once the general direction has been set), but rather
 enforcing a limited set of standard approaches, instead of allowing
 whatever creatives (ab)uses developers can think of, only to find out
 months and years down the road that they created a huge mess. Think of
 this as the namespace version of "decisions, not options".

 > Because the implementation of that autoloader is not SOLID.

 I'm not sure what you mean. Composer is certainly not 100% SOLID (I'd love
 to see any bigger project that is, to be honest), but I am pretty sure
 they come closer to that goal than the WordPress codebase. Is a specific
 "design pattern usage" of Composer the issue?

 > In my opinion, an ideal solution would be to provide a flexible core
 autoloader and afterwards integrating composer for dependency management
 by pluggin in the core autoloader to composer via a composer plugin.

 I'm not saying that we should reduce ourselves to a build-time only
 Composer autoloader. Having something that can be managed at runtime would
 be great! But I would recommend not building a custom autoloader until
 some preconditions have been met (PHP 5.3 with namespaces, WP
 autoloadable). We'll be in a better position to build the autoloader
 correctly from the start, and put in sane requirements (namespaces!) that
 avoid creating a huge conflict-ridden pool of buggy plugins. Composer
 would allow us to quickly have a working playground to already use and
 improve autoloading in Core until the preconditions have been met, while
 probably improving memory usage in the process.

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