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

 Replying to [comment:150 MikeSchinkel]:
 > 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.

 No worries, and thanks for taking the time to clarify.

 > > 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.

 Discussed this argument [/ticket/37699#comment:72 here]

 > > 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.

 We are talking about a very specific problem here, and the solution we're
 proposing has been considered a best practice for pretty much the entire
 PHP ecosystem for years now. I agree that one should always apply critical
 thinking before accepting "best pratices", but I am fully confident about
 our assertion here.

 > It is not nearly as an autoloader that works like this:
 > {{{
 > function _autoload( $class ) {
 >    if ( isset( self::$_classmap[ $class ] ) ) {
 >         require self::$_classmap[ $class ]
 >    }
 > }
 > }}}

 As I already dissected in a later comment, that is pretty much exactly
 what the Composer ClassMap loader does, plus a single additional
 instruction to normalize the class name, so that it does not break with
 absolute class names (which the above one probably does).

 > > 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.

 Composer has no defaults. Its defaults are to do nothing at all. If you
 are talking about any particular way of setting it up, that's entirely
 configurable.

 One more though on the general direction of this ticket:

 My preference would be to only consider Composer as built-time tool for
 now to build a 5.2-compatible class map that WordPress Core can use. Then
 use this to modify Core so that it can make better use of the autoloader.
 I expect his to have a positive impact (directly and indirectly) on the
 code quality and architecture of Core.

 Considering writing an API to provide a class autoloader to plugins &
 themes is too early right now, and not all of the preconditions for
 properly designing something like this are met yet.

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