Re: Merging PHPLIB into PEAR

Quoting Kristian Koehntopp <kris@koehntopp.de>: > Should your data source change, change your subclass > definition. Should your error handling need changes, change > the subclass definition. The change will be uniform, and > application wide. No need to touch any source file, as the > change is managed centrally from your subclass definition. > > The behaviour of CT_*, Session and other PHPLIB classes is > similar - all application wide defaults are inherited and > overridden, not parametrized on each page, as this makes verbose > code and is difficult to change. I'm afraid that I disagree completely. If you look at the Log classes that are in PEAR, you'll see that they are built like the DB classes are. The Log_sql class uses DB to talk generically to databases. The way things are, if I want to change my datastore, all I do is change a single config file (which contains the parameters passed to Log::factory()), and it all still works. You change _no_ code in any of your application. Just the configuration file. With the phplib model, if I want to switch from using syslog to using sql logging, I need to write at least one (and probably two) new subclasses, I need to make sure that the various subclasses are included by prepend.inc, and I have to know enough about php classes to edit things without breaking them. From the point of view of someone who builds applications that other people use, the first scenario is far easier. You keep everything in one config file, and you keep it much simpler for people. -chuck -- Charles Hagenbuch, <chuck@horde.org> Entropy. It's what's for dinner.