- constant
- A constant is an identifier (name) for a simple value. As the name suggests, that value cannot change during the execution of the script (except for magic constants, which aren’t actually constants). A constant is case-sensitive by default. By convention, constant identifiers are always uppercase.
Practically, it’s as easy as:
define('DATABASE', 'thedatabase');
Constants are useful in a lot of cases:
- Configuration directives
Storing database connection information is plain easy and available everywhere.
define( 'DATABASE', 'thedatabase' ); define( 'USERNAME', 'theuser' ); define( 'PASSWORD', 'thepass' ); define( 'HOSTNAME', 'localhost' );
These have global scope, cannot be tempered with and can be accessed from everywhere. How easy is that?
- Anti-hack techniques
You can make sure nobody accesses and uses your files remotely by checking a constant that you only define in one place, unaccessible from the web.
if(!defined('ANTIHACK_FG3N4890FN4334G3GH')) die('You naughty');
- Various flags
Usually you need here and there to set some flags that activate or dezactivate some functionalities in your application, including debug flags.
define('USE_CACHE', true); //.... some code.... if(constant('USE_CACHE')) { //... cache data here }
By using
constant()
, we don’t get a notice if the constant is not defined, and to disable the cache, you can take any approach you find suited: either set the defined constant to “false”, or comment it, the outcome is the same and you don’t get notices and warnings in your code, even if you completely remove the constant from your code.
So, you define the constants with define(), you check to see if certain constant is defined with the defined() function and you get the value of a constant that could or could not be defined using constant().
Using constants in classes
Along with the wonders of OOP in PHP 5 came the possibility to define constants inside classes. For example:
class AppSettings { const DATABASE = 'thedeployer'; const HOSTNAME = 'localhost'; const USERNAME = 'deployer'; const PASSWORD = 'thepassword'; public function __construct() { echo 'database = `' . self::DATABASE . '`'; echo 'hostname = `' . self::HOSTNAME . '`'; echo 'username = `' . self::USERNAME . '`'; echo 'password = `' . self::PASSWORD . '`'; } // END constructor } // END class echo 'database from outside = ' . AppSettings::DATABASE;
Basically, the constants ar a part of the class definition, you don’t have to actually execute code to define the constants and they are available immediately for use. And most important, you don’t have to instantiate a class to access it’s constants, and you always know where to look for the definition.
The advantages and differences that one should remember when using constants and the reasons to use constants in classes rather than just floating around in your code are:
- Constants defined in classes do not show up in the global scope.
There is a stack where PHP holds all the constants and it’s a rather large list. It’s nothing like the variables which are a total of 4 superglobals that exists when a script starts. To see the list of defined constants, just run:
print_r(get_defined_constants());
You’ll get a huge list of approximately 1760 defined constants when your script hasn’t got a line. This is a required compromise, because these constants include TRUE, FALSE, error codes, constants defined by enabled extensions and some other useful constants. This is why your constants shouldn’t go here. If you define your constants as part of some classes, they remain within the class definition and don’t end up in the constants pool. And don’t worry, even if they’re defined within a class, they are available everywhere, just like a normal constant.
- Grouping the same type of data together.
Usually, you can define a class that just deals with every piece of configuration data your application needs, just like de example above. This means that all your constants are in one place, and if you need to change a constant, you only need to find where the class is defined and change your info. You even have the class name, because you’ll be using the constants defined in some class this way:
echo 'database from outside = ' . AppSettings::DATABASE; // this means that the "DATABASE" constant is defined in the "AppSettings" class.
How easy is that?
- Available without executing code.
Since the constants are part of the class definition, they’re available before even the first line of actual code is executed.
- Class autoloading power.If you have the autoload feature in use in your application, you’ll get another advantage. You’ll have the constants defined with a single call to the wanted class that contain the constants. The autoloader will locate an load you class.
These are just a few things that need to be said and noted when addressing constants. Be careful not to use constants where they’re not appropriate. For example in internationalization. Don’t define the i18n labels in constants. That’s a very greedy approach. Use gettext extension or some other dedicated solution for this. Using constants is just bad.
Happy coding and have a nice day!
Storing database configuration (any configuration, really) information inside a class is bad form. If you’re using any sort of version control system, you now have to template your AppSettings class.
Comment by ZacharyDanger — April 15, 2009 @ 22:32
Well, I have to disagree. I use subversion for all my projects and my config file IS a class. There’s no need to add code in the configuration class.
And regarding versioning config files, I keep in the repository files like config-dist.php, and after deployment I rename them to config.php.
Comment by Lucian Daniliuc — April 16, 2009 @ 08:31
“dezactivate”, yeah right
)
Comment by anonymous — June 20, 2009 @ 14:55