[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:  4.7
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:
-----------------------------+------------------

Comment (by MikeSchinkel):

 > However, what you call "groupthink" (which I find rude, tbh)

 I apologize if it came across as rude. That was not my intention.

 I used "groupthink" in the same context that management consultants use it
 to try to improve business decision making,
 [https://www.mindtools.com/pages/article/newLDR_82.htm for example].
 Think of it like me saying ''"Let me propose a strawman"'' but in a
 different context.

 > is an effort to bring de facto PHP best practices to WordPress, trying
 to get it out of the "legacy software" drawer it keeps getting put into
 more and more.

 See [/ticket/37699#comment:66 my comments ''(to you)'' here] about there
 being different levels of programmers and how we should not be forcing all
 of them to be at the highest skill level.

 Think of them as diffferent constituents, all of which we should guard
 their interests and not forsake any of them.

 > I think that all the people contributing on Trac are interested in
 seeing a bright future for WordPress,...

 And my reason for pushing this issue is that I think that taking it down
 the path or ratcheting up the skill level required to be productive with
 WordPress would dim that future significantly.

 > If you use a tried and tested autoloader, there's no need to step
 through it with XDEBUG, so I don't see why this would be relevant.

 In theory.  But the reality is that when debugging you are in discovery
 mode and frequently you are still trying to get your bearing so frequently
 (at least I) accidently step into autoloaders when I do not intend to.

 > If it is problematic to apply (de-facto) best practices to a project,
 chances are the best practices are not a fault. This probably just points
 to an inherent design flaw that should be addressed.

 You are assuming that so-called ''"best practices"'' are actually fit for
 purpose.  That logic is called
 ''"[https://en.wikipedia.org/wiki/Argument_from_authority appeal to
 authority appeal to authority]"'' and is a logical fallacy.

 In my 25+ years of professional development I have  seen many ''"best
 practices"'' exposed as only being ''Well it seemed like a good idea at
 the time.''  So we should not view  ''"best practices"'' as a sacred sword
 and instead validate each practice to see if it actually applies in the
 current context.

 > but premature optimization at this point is completely useless (and
 counter-productive),

 Unless, by your arguments in support of your positions, that doing so
 would paint us into an architectural corner that we could not later
 extract ourself from. And it is my currently believe that once Composer
 gets into core it will be there until WordPress is no longer relevant such
 like SVN and other infrastructure technologies.

 > That being said, the Composer autoloader is already tightly optimized in
 a proven way, and it is difficult to get any improvements over it with
 anything but very simple scenarios.

 It is not nearly as an autoloader that works like this:

 {{{
 function _autoload( $class ) {
    if ( isset( self::$_classmap[ $class ] ) ) {
           require self::$_classmap[ $class ]
    }
 }
 }}}

 > this discussion is not relevant for the autoloader and should be done in
 the context of the WP Coding Standards efforts.

 Beg to disagree. The autoloader is in part driving the requirement.  To
 discuss in WP Coding Standards would be the cart driving the horse.

 > The whole point of a class map autoloader is to associate arbitrary
 filenames with class names. If you can determine one from the other, you
 don't need a class map. You can just use a PSR-0 or PSR-4 autoloader.

 PSR-0 and PSR-4 are optimized for PHP framework style projects.  WordPress
 organizes its code differently and thus -- with the exception of using
 libraries from packagist.org on WordPress -- PSR-0 and PSR-4 are not a
 good match for WordPress.

 And classmaps can easily be generated.

 > I fail to see how that would be preferable to have a mature, 5-year-
 tested class map builder

 Because Composer's defaults actively work against WordPress's
 architecture.

 You don't use a sports car to haul a load of hay, even if it is the best
 damn sports car in the world.

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