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
