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

WordPress Trac noreply at wordpress.org
Thu Mar 31 14:56:05 UTC 2016


#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 giuseppe.mazzapica):

 Hi all,

 I have a major concerns here.

 The first one is that most of core files containing classes, does not
 ''just'' contain classes.

 In fact, many of them also contain function definitions, function calls,
 constants definitions... and so on. All things that actually force those
 file to be required eagerly (no autoload).

 The other concern is that some files contain more than one class. It means
 those files does not follow WordPress coding standard
 (https://make.wordpress.org/core/handbook/best-practices/coding-
 standards/php/#naming-conventions):

 > class file names should be based on the class name with class- prepended
 and the underscores in the class name replaced with hyphens, for example
 `WP_Error` becomes: `class-wp-error.php`

 An example (among literally dozens) the class `WP_MatchesMapRegex` is
 located in a file named `class-wp.php` that is so named because ''also''
 contains the class `WP`.

 Not to talk about some classes that are placed pretty much arbitrarily:
 `wpdb` class is in `wp-db.php` and `WP_Query` class is in `query.php`.

 A "sane" autoload will need:

 - to be able to easily match a class to a file name. This can be achieved
 by having one class per file, following coding standards for naming
 - don't be forced to hard-require files because of function / constant
 definitions or client code. This can be achieved by putting only class
 definitions in class files.

 Until those things are done, we can have only a deficient autoloader.

 To be fair, the first point could be achieved implementing a map from
 class to file name:

 {{{
 function wp_autoload_map() {
   global $wp_autoload_map;
   if ( ! $wp_autoload_map ) {
     $wp_autoload_map = array(
       'WP'                 => 'wp.php',
       'WP_MatchesMapRegex' => 'wp.php',
       'WP_Query'           => 'query.php',
       'wpdb'               => 'wp-db.php',
       // and other 257 entries here...
     );
   }
   return $wp_autoload_map;
 }
 }}}

 but this not the best solution ever and does not solve the issue of
 function / constants definition and client code in files that contain
 class definitions...

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


More information about the wp-trac mailing list