Config include

Hi !

Usualy in my configuration php file to include (i usualy named it core.inc), i prefer use constants unlesse variables ! :-)

Example
define("NUM_ROWS",15);

Right but you cannot change constants once defined.

The point of using configuration variables as a class is that you just pass the configuration options object to other classes that you need to check the application options.

Since the idea is to change some options for each of the types of environment, those values are better defined as class variables.

I think using constants is safe:

While the script is running, the values of the config settings won't change. Yes, they differ between development and production, but these are two different servers, and two different invocations of the PHP script.

That is not the point I am making.

If you followed the point of the article, you can see there is a configuration class that defines default option values for use in the production environment.

Any of the environments that require different values than the default, need to redefine the default values, so constants won't do.

Another problem of global constants (or even global variables) is name collision. If you have different parts of your application using constants with the same names but different meanings, you may run into inconsistency bugs.

That is why configuration options are better encapsulated in a class precisely to avoid name collision.

Sorry, Manuel. Yes, you're right. Not sure how I could have missed that.

Ok,

But you as programmer do not define two constants with somme name, right ?

I define these constants to be the most understand easly, like
define("MAX_ROWS",15);

If i want to pass multiples values, i use arrays !
$a = ("car" => "blue", "apple" => "red")
I call
$a["car"]
...

Constancts in most cases is most useful, when you dont want to modify these value ;-)

José,

here is the problem Manuel wants to solve:

Suppose you have an app with 10 config variables. Suppose that you expect 3 of them to be different in the test environment than in the production environment.

Manuel allows you to have one config file with the 10 production values, and then add another one for the test environment that just overrides the 3 values that are different from production.

Now suppose you use constants and put the 10 production values into a config file. Then you need to copy that file and edit it to create the testing config file. So now you have duplicated 7 values.

Another approach is to split the 7 common values into a common config file, then create one production config with 3 values and a testing config with 3 values. But what if you discover that an additional value becomes environment-specific? Then you have to move it out of the common file into all the environment specific files.

With Manuel's approach you're more flexible: You can put all production values into one file, then override some of them for a specific environment as needed.

That said, if the config files are small, the duplication might not be much of an issue.

Kai

Exactly.