[wp-trac] [WordPress Trac] #22251: Helper function to simplify checking for constants

[WordPress Trac]

#22251: Helper function to simplify checking for constants
-------------------------+------------------------------
 Reporter:  evansolomon  |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |
-------------------------+------------------------------
Changes (by MikeSchinkel):

 * cc: mike@… (added)


Comment:

 Rather than go the direction of creating an access function I'd propose
 WordPress slowly deprecate all uses of PHP constants in the WordPress
 ecosystem and use another approach.

 One potential other approach would be to deprecate constants in favor of
 `UPPERCASED` properties on the `$wp` object ''(uppercased properties
 should not conflict with current or I assume otherwise future potential
 "non-constant" properties.)'' This approach would change `WP_DEBUG` to be
 `$wp->DEBUG`.

 Further for this approach we could:

 - Add a magic `__get()` method to class `WP` that would return `false` for
 any uppercased properties that have not been previously set and set the
 property as false to avoid future `__get()` method calls.
 - Add a magic `__set()` method to class `WP` that would define a PHP
 constant if not previously defined and if `$wp->LEGACY_CONSTANTS == true`.
 - A `wp_const` class defined in `/wp-load.php` to be used as a proxy for
 setting constants on `$wp` prior to the instantiation of `WP` and
 assignment to `$wp` that occurs in `/wp-settings.php`.

 This approach would allow:

 - Access without having to test for existence.
 - Fast access to constants, i.e. it would not require the overhead of a
 function call in most cases.
 - Gradual migration, first for core and then for plugins and themes as
 developers decide to change.
 - Display of a "deprecated" message if `$wp->WARN_CONSTANTS == true` by
 testing `get_defined_constants()` in a `'shutdown'` hook, or similar.

 This approach makes sense because:

 - The `$wp` variable is ''the'' global object in WordPress and real
 constants are in the same scope.
 - It adds very little code and effectively no overhead compared to the
 current case.
 - It is consistent with existing practices as practically every entry-
 level plugin and theme developer understands the use of "`global wp;`"
 and/or "`$GLOBALS['wp']`.

 I've implemented a proof-of-concept and it seems to work extremely nicely,
 better than I could have hoped for, actually.  If I get positive feedback
 on this idea I'll post the POC as a new ticket and a patch.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/22251#comment:5>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software