RE: [PEAR-DEV] do pear packages create their own seperate DB connections?

From: Date: Tue, 22 Apr 2003 21:56:15 +0000
Subject: RE: [PEAR-DEV] do pear packages create their own seperate DB connections?
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-15358@lists.php.net to get a copy of this message
> From: Hans Lellelid [mailto:hans@appliedsec.com] > Sent: Tuesday, April 22, 2003 10:34 PM > Jon Wood wrote: > > >>class x > >>{ > >> function &getInstance() > >> { > >> $varName = '__'.__CLASS__; > >> if (!isset($GLOBALS[$varName]) || > >> get_class($GLOBALS[$varName])!=__CLASS__) { > >> $GLOBALS[$varName] =& new x(); > >> } > >> return $GLOBALS[$varName]; > >> } > >>} > >> > >>this way it gets saved in the global namespace, i know. its not really > >>cool. but may be someone knows a better and nicer way > >>or is it even simpler with php4? > >> > >> > >Is there a problem with statics? That's a serious question... I thought > >from reading the docs they're in v4, but I'm not certain. > > > >Jon > > > Statics are a much better way to handle this IMO. There is some fringe > behavior with statics in singleton method, however. (At least when using > PHP4 which doesn't have class-scope static variables). > > I generally use: > > function &getInstance() > { > static $instance; > if (!isset($instance)) { > $instance = new Class(); // NOT by reference > } > return $instance; > } > > The catch is that you cannot assign static vars by reference. That > means that you cannot do $instance = &new Class(). Usually this is > fine, sure it's making a copy originally, but every time you call > Class::getInstance() you are receiving that same copy (i.e. only one > copy is ever made). Sometimes, however, making a copy of the class at > instantiation returns a significantly different object. I believe that > PEAR's Log class is an example of a class that should always be returned > by reference (at least when using the factory() method), because in the > construction of the class listeners are bound to _the_ instance of the > class being constructed: > > $Log = &Log::factory('file', $params); // not the same as $Log = > Log::factory('file', $params); > > (Not sure if that's a valid factory() signature, but it's just for > example.) this would also create problems I fear for MDB I think. Also I don't think its such a huge issue to have a global array in order to implement a singleton. We don't need to get so jived up about OOP. Its PHP afterall. If there is a non OOP solution that fits I don't see a problem. The global variable has the $_MDB prefix so I think conflicts should be very rare :-) BTW: Hmm actually I think I need to take a look at the MDB transaction handling. I could probably use a PEAR destructor there instead of the current solution. Regards, Lukas

« previous php.pear.dev (#15358) next »