[wp-trac] [WordPress Trac] #36335: Next generation: core autoloader proposal

WordPress Trac noreply at wordpress.org
Thu Sep 15 06:44:31 UTC 2016


#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:190 MikeSchinkel]:
 > Replying to [comment:182 chrisvanpatten]:
 > > If the goal is to ... make WordPress more consistent with generally
 accepted PHP best practices

 > After 7 years of working with WordPress professionally ''(and numerous
 programming languages before WordPress)'' I have come to the conclusion
 that WordPress best practices and PHP best practices are often at odds
 with one-another.

 I don't think there's such things as WordPress best practices and PHP best
 practices, I guess you're thinking about the WordPress Coding Standards
 here, which are mostly about style. You don't get to choose "your own
 personal best practices", they are an industry consensus, with the
 industries being web development and/or the more general software
 development.

 So, there's "The WordPress Way" and there's industry best practices, and
 yes, these two are sometimes at odds. The question then is: "Are we
 forced/required to adhere to industry best practices, or is it preferable
 to keep our own ways?"

 No one forces you to embrace best practices, but it is generally in your
 own best interest. The best practices are derived from experience that has
 come from projects that have the breadth, depth and scope to find out what
 impact initial design choices will ultimately end up having. They allow
 you to avoid making costly mistakes because of design choices that
 initially seem to be a good solution, and end up being the contrary.

 What kinds of best practices are we touching upon here, when we are
 talking about "Using Composer to build an autoloader vs building a custom
 one"? ''Note: I'm just improvising to come up with a list here, and I
 don't really know where to find a meaningful "list of software best
 practices" without investing days of work. Let me know if I missed
 something obvious.''

 1. Use mature, battle-tested libraries
 2. Use standards
 3. Don't reinvent the wheel
 4. Aim for interoperability
 5. Keep the number of external dependencies low
 6. Avoid tight coupling to a framework

 Comparing Composer autoloader vs custom autoloader would result in
 something like this:

 {{{
  Composer --- Custom
      +     1.    -
      +     2.    -
      +     3.    -
      +     4.    -
      -     5.    +
      +     6.    -
 }}}

 This simplified enumeration is of course non-sense. But I wanted to
 illustrate what the types of "best practices" are that we are talking
 about here. This is not something like "spaces vs tabs"...

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


More information about the wp-trac mailing list