define() will define constants exactly as specified. So, if you want to define a constant in a namespace, you will need to specify the namespace in your call to define(), even if you're calling define() from within a namespace. The following examples will make it clear.

The following code will define the constant "MESSAGE" in the global namespace (i.e. "\MESSAGE").

Not sure why the docs omit this, but when attempting to define() a constant that has already been defined, it will fail, trigger an E_NOTICE and the constant's value will remain as it was originally defined (with the new value ignored).

I think worth mentioning is that define() appears to ignore invalid constant names.One immediate implication of this seem to be that if you use an invalid constant name you have to use constant() to access it and obviously that you can't use the return value from define() to tell you whether the constant name used is invalid or not.

Some people like to have an ambiguous, engine-agnostic database include specified by assigning a single config variable to one of a series of constants. Unfortunately, this can easily become needlessly clunky if these defines are handled in an included config.php file, since more than one hook will throw an ugly "already defined" error.

Here's a simple way to accomplish this architectural model without having to create a bunch of clumsy sanity checks that compromise scalability:

Just like define(), defined() will check for constants exactly as specified. So, if you want to check a constant in a namespace, you will need to specify the namespace in your call to defined(), even if you're calling defined() from within a namespace.

To check for a defined constant within current namespace, you can use __NAMESPACE__ magic variable:

There's an undocumented side-effect of setting the third parameter to true (case-insensitive constants): these constants can actually be "redefined" as case-sensitive, unless it's all lowercase (which you shouldn't define anyway).

The fact is that case-sensitive constants are stored as is, while case-insensitive constants are stored in lowercase, internally. You're still allowed to define other constants with the same name but capitalized differently (except for all lowercase).

A third party plugin might attempt to define a constant for which you already set a value. If it's fine for them to set the new value, assuming you cannot edit the plugin, you could define your constant case-insensitive. You can still access the original value, if needed, by using any capitalization other than the one the plugin uses. As a matter of fact, I can't think of another case where you would want a case-insensitive constant...

As you can use function within the heredoc notation the idea is to use a fonction to return the value of the constant.Be carefull, to use a function, it's necessary to declare the name of the function as a variable and to use that varaible during the "call" of the constant.

if (is_null($value)) {define($constant_name, ++$increment); // $increment=$increment<<1 for bitmask} else {define($constant_name, $value); if (is_numeric($value)) {$increment = $value; } }}?>If you pass it a second argument it defines it normally, and resets the increment if the value is numeric. This way the function can replace define, and you can reset the counter for a new set of constants.<?phpadefine ('RULE_CALLBACK_FORMAT', 1); // 1adefine ('RULE_CHANGE_CALLBACK_ON_ERROR'); // 2adefine ('RULE_CHANGE_COMPARE_DATE'); // 3adefine('KEYWORD', 'hodgepodge'); // hodgepodge <-- defined normallyadefine ('RULE_CHANGE_ON_DATE'); // 4

I realize this is not ideal, either for performance or for convenience of being able to refer to constants without regard to scope, but it is a workaround that works. Depending on your application, it may be easier to shift your paradigm a bit and use the following method instead, declaring your constants as variables first:

The described behavior has nothing to do with the fact that there is a constant in the condition.

Comparing a non-numeric string to the integer 0 by using == will return true, since the string will be casted to integer - which will be zero. If your string starts with a number, it will be castet to an integer with the number as value.

To avoid the described behavior, you should use === instead of ==.

Finally, the behavior discribed by mittiprovence is exacly the expected behavior as defined in the manual.

Note that define don't care at all about the constant name, you can give everything as a constant name, even if the PHP documentation says that the allowed characters are [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*

Just try this :

<?php define('anything::()$', 'test'); ?>

You won't be able to access this constant though, it will throw a parse error, either through constant() or define(), but if you do that :

<?php print_r(get_defined_constants()); ?>

You will see that the constant is registered at the end of the array. Yes that's totally useless. But you can try other things that will work with constant() :

<?php define('...', 'test'); echo constant('...'); ?>

Will echo 'test'. Yeah that's a pretty strange behavior.

And please note that defining object constants outside of objets don't work :

Watch out. You can define a new constant with the name NULL with define("NULL","FOO");. But you must use the function constant("NULL"); to get it's value. NULL without the function call to the constant() function will still retrieve the special type NULL value.Within a class there is no problem, as const NULL="Foo"; will be accessible as myClass::NULL.