Re: RFC on merge of PHPLib and Pear

Hi, * Stig Sæther Bakken wrote: > > > Your argument isn't exactly convincing. Put it this way: I could always > > > subclass PEAR's DB_mysql if I wanted to, and supply the parameters in the > > > class. Could I use a config file without re-writing phplib's DB_sql, or setting > > > the parameters manually after instantiating the object (ugly)? No. Chuck, of course you can set the parameters manually after instantiating the object (seems you really haven't dealed with PHPLIB seriously?): <?php $db = new DB_Sql; $db->Host = "localhost"; $db->Database = "redsys"; $db->Passwort = ""; $db->User = "root"; $db->query("select * from seite"); while ($db->next_record()) { print "ID: ".$db->f("sid")."<br>\n"; } ?> This can be a disandvantage if you remind the example with the nested whiles: $db = new DB_Sql; $db1 = new DB_Sql; Now you have to objects where you have to give _twice_ the same config parameters: $db->Host = "localhost"; $db1->Host = "localhost"; ... instead of the centralized way of local.inc. (One could also say, local.inc _is_ the config file of the PHPLIB classes.) But, and now we come to Stig: > Subclassing limits your options to just subclassing. In Chuck's > DB_mysql example, runtime configuration gives you one more option. See above, you have runtime configuration. But, repeating again, PHPLIB's nature is subclassing. If you want config files with $PARAMS["db_host"] = "localhost", then use $db->Host = $PARAMS["db_host"] from the above example or use another system. Chuck's argumentation seems to me a little bit weird: if a class foobar only supports an API with a defined way of how to configure it, you can't say "But I want that in _my_ config way!". Would be the same as if I would write "Hey, I don't want to give my datas over the XMLRPC interface to this class, I want that the class pulls the datas from outside my car!". -- Björn Schotte bjoern@php.net http://rent-a-phpwizard.de/ bjoern@baer.main.de Software dev advocate: http://www.advogato.org/person/baerli/