You're wrong. Read an OO programming book. There won't be a new instance of GoodSingletonModel because the instances array sits in SingletonModel. BadSingletonModel only overwrites getInstance and $instance only for itself.
- David ________________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of graeme Sent: Saturday, July 02, 2005 12:46 PM To: Agavi Development Subject: Re: [agavi-dev] Singleton No what I'm trying to say is this: GoodSingletonModel extends SingletonModel { // lots of model specific code } BadSingletonModel extends SingletonModel { // lots of model specific code plus protected function getInstance { $instance = array(); // just for the hell of it parent::("BadSingletonModel"); // I'm an empowered programmer who doesn't know what I doing } } ... $gSM = getInstance("GoodSingletonModel"); $gSM->.... // lots of code setting up // at this point the $instance array has an entry for GoodSingletonModel // so $gSM2 = getInstance("GoodSingletonModel"); would get the instance $bSM = getInstance("BadSingletonModel"); // now the $instance array doesn't have an entry for GoodSingletonModel // so $gSM2 = getInstance("GoodSingletonModel"); would create a new instance By making $instance private the above code for BadSingletonModel would fail unless $instance is redeclared and then SingletonModel class would use its version whilst the BadSingletonModel would use its version, and GoodSingletonModel would still be happy. graeme. David Zülke wrote: Uh... no, because the other models that are supposed to work as singletons will still "extends SingletonModel" and thus not be affected if "MyCustomModelThatImplementsSingletonDifferentlyModel extends SingletonModel" should decide to redeclare $instance or getInstance() - David -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of graeme Sent: Saturday, July 02, 2005 12:23 PM To: Agavi Development Subject: Re: [agavi-dev] Singleton I guess it a matter of style, but by making it private you are essentially saying this is my variable and I'm looking after it. I would also add that by making it protected a person could come along and not redeclare it but clear it meaning that other singleton objects will be lost and so they will need to be recreated in the process losing the data that was put in them. graeme David Zülke wrote: You're right, but what's the problem about the var being protected. Not publicly accessible, but you can change it by subclassing. I'm sure that if I make it private, one day someone will show up and ask why it isn't protected because he needs to do blah blah blah ;) - David ________________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of graeme Sent: Saturday, July 02, 2005 12:00 PM To: Agavi Development Subject: Re: [agavi-dev] Singleton But why would you want to offer that? Surely the point of putting code in a framework is so that a developer doesn't need need to go down that path. All it would provide (as I can see) is the ability to create a smaller array with which to do the search for isset. graeme. David Zülke wrote: It's protected to allow sublasses to implement the singleton functionality themselves. You cannot redeclare a private member, and $instance is the common name for the instance variable. - David -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of graeme Sent: Saturday, July 02, 2005 11:25 AM To: 'Agavi Development' Subject: [agavi-dev] Singleton Just had a peek at the code for SingletonModel. (revision 151) I think the $instance array should be private. Only that class wants to be able to manage the array list whilst, yes constructors should be protected allowing the subclasses to modify the constructor. graeme. _______________________________________________ agavi-dev mailing list [email protected] http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev _______________________________________________ agavi-dev mailing list [email protected] http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev _______________________________________________ agavi-dev mailing list [email protected] http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev _______________________________________________ agavi-dev mailing list [email protected] http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev _______________________________________________ agavi-dev mailing list [email protected] http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev _______________________________________________ agavi-dev mailing list [email protected] http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev
