RE: [PEAR-DEV] do pear packages create their own seperate DB connections?
| From: | Lukas Smith | 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