Posted by malatestapunk on 08/16/06 06:09

> Constants? If they're statical all the time I'd think this is better.
> Constants are freely available in functions without explicitly making them
> global. Also, constants defined in functions are automatically global for
> the rest of the script/classes/objects/functions.
>
> I normally have an ini-file for different project with similar code, and at
> the start of the script:
> $settings = parse_ini_file("settings.ini");
> foreach($settengs as $key => $value){
> define($key,$value);
> }
>
> > Maybe I could just have a "SiteParameters" class, create a new
> > instance, and get the information that way?
>
> Which would result in first making this class global, then getting the value
> out of it. I don't think this is such a good idea.
>
> Grtz,
> --
> Rik Wasmus

Constants are really good for this, as configuration info is statical
by nature. But you could go with the class as well - there is no need
to make the configuration object global. You could implement it as
singleton, and then call MyConfigClass::getInstance() when you need a
populated configuration object. I personally prefer doing things this
way as it keeps everything nicely organized.

The main thing is to provide methods for getting and setting member
values and use only these for accessing members, as this gives your
class the access control. This is especially important in php4, as it
exposes all members as public.

As for general OO vs functional programming thing in php, it still
seems to me more like a matter of taste. Things are different with
php5, but most servers still run php4. However, I'd go with using
classes even in functional programming since that keeps similar
functions neatly organized under a single namespace. You'll appreciate
this as soon as your code starts to grow in size.

In my experience, the OO way of doing things proven to be very usefull
when your requirements change (and they always do). It's was so much
easier for me to design a large set of small classes while unit-
testing along the way. Then, when the requirements get updated, it's
almost trivial to implement the changes and repeat the unit testing
cycle to make sure everything still works as it should.

[Back to original message]