[wp-trac] [WordPress Trac] #42264: Systematic way of dealing with compat code and polyfills

[WordPress Trac]

#42264: Systematic way of dealing with compat code and polyfills
----------------------------+------------------------------
 Reporter:  schlessera      |       Owner:
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Bootstrap/Load  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+------------------------------
Description changed by westonruter:

Old description:

> The way compatibility code and fallback/polyfill functionality is
> currently handled has a few issues:
>
> * As everything resides in one big file, all of the code is parsed every
> time.
> * As everything resides in one file, problems like the PHP 7.2 parsing
> error for the autoload polyfill can crop up (as the polyfill is written
> with now deprecated code).
> * If the requirements change, it is non-trivial to remove unneeded code
> again.
>
> I'd like the suggest a more systematic way of loading the compatibility
> layer. The basic premise is that the PHP version of the current server is
> detected, and then an individual compatibility file is loaded for each
> version that is not already supported by the server.
>
> This provides a clean way of structuring the compatibility layer, giving
> a good overview of what is needed when, and what can be discarded. It
> also only loads the code that is needed.
>
> Here's the main mechanism that would make this work:
>
> {{{#!php
> // Check the PHP version and load the corresponding compatibility files.
> // The fall-throughs (missing breaks) are intentional, as this makes sure
> that
> // all compat files - starting from the first required one - will be
> loaded.
> switch ( substr( PHP_VERSION, 0, 3 ) ) {
>         case '5.2':
>                 require ABSPATH . WPINC . '/compat/php-5.2.php';
>         case '5.3':
>                 require ABSPATH . WPINC . '/compat/php-5.3.php';
>         case '5.4':
>                 require ABSPATH . WPINC . '/compat/php-5.4.php';
>         case '5.5':
>                 require ABSPATH . WPINC . '/compat/php-5.5.php';
>         case '5.6':
>                 require ABSPATH . WPINC . '/compat/php-5.6.php';
>         case '7.0':
>                 require ABSPATH . WPINC . '/compat/php-7.0.php';
>         case '7.1':
>                 require ABSPATH . WPINC . '/compat/php-7.1.php';
>         case '7.2':
>                 require ABSPATH . WPINC . '/compat/php-7.2.php';
>         default:
>                 require ABSPATH . WPINC . '/compat/default.php';
> }
> }}}
>
> Note the fall-throughs of the case statements. As an example, if the
> current server would be running PHP 5.6, the above mechanism would load
> the compatibility files for 5.6, 7.0, 7.1 and 7.2.
>
> Inside of the individual files, you'd have fallbacks and polyfills, that
> are needed for the '''version it resides in and all previous versions'''.

New description:

 The way compatibility code and fallback/polyfill functionality is
 currently handled has a few issues:

 * As everything resides in one big file, all of the code is parsed every
 time.
 * As everything resides in one file, problems like the PHP 7.2 parsing
 error for the autoload polyfill can crop up (as the polyfill is written
 with now deprecated code).
 * If the requirements change, it is non-trivial to remove unneeded code
 again.

 I'd like the suggest a more systematic way of loading the compatibility
 layer. The basic premise is that the PHP version of the current server is
 detected, and then an individual compatibility file is loaded for each
 version that is not already supported by the server.

 This provides a clean way of structuring the compatibility layer, giving a
 good overview of what is needed when, and what can be discarded. It also
 only loads the code that is needed.

 Here's the main mechanism that would make this work:

 {{{#!php
 <?php
 // Check the PHP version and load the corresponding compatibility files.
 // The fall-throughs (missing breaks) are intentional, as this makes sure
 that
 // all compat files - starting from the first required one - will be
 loaded.
 switch ( substr( PHP_VERSION, 0, 3 ) ) {
         case '5.2':
                 require ABSPATH . WPINC . '/compat/php-5.2.php';
         case '5.3':
                 require ABSPATH . WPINC . '/compat/php-5.3.php';
         case '5.4':
                 require ABSPATH . WPINC . '/compat/php-5.4.php';
         case '5.5':
                 require ABSPATH . WPINC . '/compat/php-5.5.php';
         case '5.6':
                 require ABSPATH . WPINC . '/compat/php-5.6.php';
         case '7.0':
                 require ABSPATH . WPINC . '/compat/php-7.0.php';
         case '7.1':
                 require ABSPATH . WPINC . '/compat/php-7.1.php';
         case '7.2':
                 require ABSPATH . WPINC . '/compat/php-7.2.php';
         default:
                 require ABSPATH . WPINC . '/compat/default.php';
 }
 }}}

 Note the fall-throughs of the case statements. As an example, if the
 current server would be running PHP 5.6, the above mechanism would load
 the compatibility files for 5.6, 7.0, 7.1 and 7.2.

 Inside of the individual files, you'd have fallbacks and polyfills, that
 are needed for the '''version it resides in and all previous versions'''.

--

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