Re: DB_Light

Not an OOP guru but wouldn't something like this work: DB::connect("light"); Where "light" loads a db class (instantiates an object) containing core methods for the relevant db. DB::connected("extended); Where "extended" loads a db class (instantiates an object) containing core methods for the relevant db (DB_Mysql) and extended methods (DB_Mysql_Extended). Regards, Paul Meagher ----- Original Message ----- From: "Lukas Smith" <smith@dybnet.de> To: <pear-dev@lists.php.net> Sent: Tuesday, December 04, 2001 1:50 PM Subject: RE: [PEAR-DEV] DB_Light > Ok, > what I envision is a system that dynamically loads the used features. So > there is no need to separate anything. > > What I am not that clear about is how to do this :-) > Any suggestions? > > Somehow I get my head into a bind very early on in the concept stage. > Anyways maybe some of those PHP OOP guru's can step up with this one. > > Obviously if its not possible to do this we will have to offer to > different packages ... or ask Zeev to somehow make it possible :-) > > Best regards, > Lukas Smith > smith@dybnet.de > _______________________________ > DybNet Internet Solutions GbR > Alt Moabit 89 > 10559 Berlin > Tel. : +49 30 83 22 50 00 > Fax : +49 30 83 22 50 07 > www.dybnet.de info@dybnet.de > _______________________________ > > > -----Original Message----- > > From: lustig@acsu.buffalo.edu [mailto:lustig@acsu.buffalo.edu] > > Sent: Tuesday, December 04, 2001 6:22 PM > > To: pear-dev@lists.php.net > > Subject: [PEAR-DEV] DB_Light > > > > OK, so I've been thinking, through all of this conversation about a > new > > DB abstraction layer. Now, it's really nice to have a full-featured, > > totally abstracted abstraction layer... however, some applications > don't > > need all of the "extras" like the DB-specific queries to do things > like > > get all of the tables, or to get all of the rows for a table and stick > > them into an array -- those types of things could be done on a > > case-by-case basis, and when you're working on an application that'll > > get tons of hits all the time (like a message board or a high-profile > > website) where the abstraction of the SQL can be left up to you and > all > > that you need is a very simple API to connect and do queries, it is a > > speed problem when you're including ~75 kb (AKA a ***lot***) of files > > with every pageload... if someone chopped out a lot of the "extra" > > features, for a streamlined version of PEAR::DB, perhaps it could be a > > new package, "DB_Light" (or something), a faster PEAR::DB. These are > > some of the things that I think should be kept in something like that: > > > > query() > > fetchInto() -- no fetchRow(), because it's extra > > isError() > > quote() > > > > There's probably more... that's all that I can think of off the top of > > my head right now (besides that I have to go to class in a few > minutes)... > > > > --Jason > > > > -- > > PEAR Development Mailing List (http://pear.php.net/) > > To unsubscribe, e-mail: pear-dev-unsubscribe@lists.php.net > > For additional commands, e-mail: pear-dev-help@lists.php.net > > To contact the list administrators, e-mail: > php-list-admin@lists.php.net > > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, e-mail: pear-dev-unsubscribe@lists.php.net > For additional commands, e-mail: pear-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net > >