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

 Replying to [comment:26 schlessera]:

 > Anther thing to consider is that the one true benefit that an autoloader
 brings to the table that you can't easily have without is the way you can
 "just use" libraries. You don't have to call any bootstrapping code that
 will `include` lots of stuff, you don't have to `include` yourself, you
 don't have to check if an external class exists first. If you now start
 with a custom autoloader specific to WordPress Core, you might be able to
 autoload a plugin's classes without `include`s (you saved a few lines of
 typing), but you blocked access to that biggest benefit of an autoloader.
 Let's be honest: all the great modern PHP libraries can saves us hours and
 days of custom development when working on a larger project '''will not be
 rewritten''' to make them work with a WP-specific autoloader! So each of
 them will need special forks/bridges/adapters to use within WordPress.
 That's not really progress, if you ask me...

 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.


 > > we shouldn't allow for registration of custom autoload rules
 > Agree, PSR-4/WP-? & classmaps should be more than enough.

 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.


 > So, if you want to bake in an autoloader into WordPress Core, why not
 just use the one that the rest of the PHP world uses?

 Because the implementation of that autoloader is not SOLID.

 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.

 However, the other way around would also be fine for me.

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