I'll have to re-think extending the class with our database class. In the
past they may not have worked well. Admittedly, our classes were written
poorly. But, now that we're massively redesigning, that may work very well.
Thanks for getting my brain-juices flowing again.
"Gurhan Ozen" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Hi Gary,
> I didn't understand what you were actually trying to do here.. You stated
> that "Our goal here is to minimize the number of database connections per
> function call." but seems like you are connecting to the database in the
> constructor? So each instance will automatically connect to the DB??
> Why don't you write a DB connection class and inherit it for every other
> class you need to write so that all of its functions will be available in
> the derived class as well and so that you won't have to call the class
> inside another class?
> -----Original Message-----
> From: Gary Cornelisse [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 14, 2002 12:47 PM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DB] DB Class pointer as var in another class
> We've been considering the following implementation of a class pointer
> within another class. Our goal here is to minimize the number of database
> connections per function call. It seems to work just fine, but I wanted
> post this up for comments. PHP 4.1.1 doesn't seem to have a problem with
> it. We have a couple classes working this way in some of our beta code.
> I've never seen anyone do this before so I just wanted to make sure we
> weren't wandering into uncharted waters.
> class my_class
> var $test;
> var $db_class;
> function my_class($test)
> $this->test = $test;
> $this->db_class = new database_class(DB_NAME);
> function get_db_info()
> ... use db here via $this->db_class ...
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php