[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    |
-------------------------+------------------------------

Comment (by rmccue):

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

 On the one hand, I think this might be be confusing, simply because it's a
 weird sort of syntax (to my eyes at least) to use `$wp->ABC` and that not
 being a proper constant. However, it is a cool idea, especially with the
 magic getter/setter. I also think it makes sense to have it under `$wp`.

 Replying to [comment:3 nacin]:
 > I think this is clever but I would like to see what some PHP frameworks
 use to work with constants (for the ones they don't avoid). It'd be nice
 to see what we can do to reduce the number of constants we have. Those 57
 instances have 30 unique constants among them.

 In most cases, they simply avoid them completely. For example, setting
 Symfony into debug mode is just another configuration option, not a
 constant. One way that this could be done in WP is to load the WP class
 before the configuration, allowing users to set e.g. `$wp->debug = true`
 in `wp-config.php`. This would be a fairly major change, I'd say.

 That's essentially the same as Mike's changes [comment:6 above]. However,
 I think the configuration file should stick to constants for most things.
 Allowing setting the properties in that manner would allow them to be set
 anywhere in the code without a complicated setter. Such a complicated
 setter would probably be a bad thing too, because I can't see how you
 could possibly code such a thing without causing huge problems.

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