Simple (?) Singleton Question

[Rob Wilkerson]

Hey all -

Not being a seasoned PHP developer, tonight I started playing with the
use of the Singleton pattern to store configuration information. What
I was surprised to find was that the instance - at least the one I'm
creating - isn't really a singleton. With each request, the
constructor is called. Isn't that very much *not* a singleton or am I
misunderstanding or doing something wrong? I'm using a pretty simple
case:

class Config
{
private static $instance;

private function __construct() {
echo '<p>Constructing</p>';
}

public static function getInstance()
{
if (!self::$instance)
{
self::$instance = new self();
}

return self::$instance;
}
public function clear() {
echo '<p>clearing...</p>';
self::$instance = null;
}
}

What am I not doing or not understanding?

Any insight would be greatly appreciated.

Rob

[Jerry Stuckle]

Rob Wilkerson wrote:

Hey all -

Not being a seasoned PHP developer, tonight I started playing with the
use of the Singleton pattern to store configuration information. What
I was surprised to find was that the instance - at least the one I'm
creating - isn't really a singleton. With each request, the
constructor is called. Isn't that very much *not* a singleton or am I
misunderstanding or doing something wrong? I'm using a pretty simple
case:

class Config
{
private static $instance;

private function __construct() {
echo '<p>Constructing</p>';
}

public static function getInstance()
{
if (!self::$instance)
{
self::$instance = new self();
}

return self::$instance;
}
public function clear() {
echo '<p>clearing...</p>';
self::$instance = null;
}
}

What am I not doing or not understanding?

Any insight would be greatly appreciated.

Rob

How about the code you're using to call it, Rob?

But one thing you need to be careful of - use references wherever
necessary. Otherwise it will make a copy, which calls the constructor.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Darko]

On Nov 14, 12:04 am, Rob Wilkerson <[e-mail]:

Hey all -

Not being a seasoned PHP developer, tonight I started playing with the
use of the Singleton pattern to store configuration information. What
I was surprised to find was that the instance - at least the one I'm
creating - isn't really a singleton. With each request, the
constructor is called. Isn't that very much *not* a singleton or am I
misunderstanding or doing something wrong? I'm using a pretty simple
case:

class Config
{
private static $instance;

private function __construct() {
echo '<p>Constructing</p>';
}

public static function getInstance()
{
if (!self::$instance)
{
self::$instance = new self();
}

return self::$instance;
}
public function clear() {
echo '<p>clearing...</p>';
self::$instance = null;
}

}

What am I not doing or not understanding?

Any insight would be greatly appreciated.

Rob

I added this code, under the class definition:
$instance = Config::getInstance();
$instance = Config::getInstance();
$instance = Config::getInstance();
$instance = Config::getInstance();

And this is the output:

<p>Constructing</p>

So, you've probably screwed other code up.

Cheers

[ZeldorBlat]

On Nov 13, 6:04 pm, Rob Wilkerson <[e-mail]:

Hey all -

Not being a seasoned PHP developer, tonight I started playing with the
use of the Singleton pattern to store configuration information. What
I was surprised to find was that the instance - at least the one I'm
creating - isn't really a singleton. With each request, the
constructor is called. Isn't that very much *not* a singleton or am I
misunderstanding or doing something wrong? I'm using a pretty simple
case:

class Config
{
private static $instance;

private function __construct() {
echo '<p>Constructing</p>';
}

public static function getInstance()
{
if (!self::$instance)
{
self::$instance = new self();
}

return self::$instance;
}
public function clear() {
echo '<p>clearing...</p>';
self::$instance = null;
}

}

What am I not doing or not understanding?

Any insight would be greatly appreciated.

Rob

That's expected. Remember that in PHP each request is independent of
the next. You'll only create one instance of your class /per request/
but it will be available everywhere you go.

Consider a database connection as an example. You open the connection
once per request, and you close it when the request is finished.
While the request is executing you only have/need a single connection
(i.e. you don't need to reconnect every time you execute a query) no
matter where in your code you go.

That's how singletons work in PHP.

[Rob Wilkerson]

On Nov 14, 9:25 am, ZeldorBlat <[e-mail]:

>
That's expected. Remember that in PHP each request is independent of
the next. You'll only create one instance of your class /per request/
but it will be available everywhere you go.

Consider a database connection as an example. You open the connection
once per request, and you close it when the request is finished.
While the request is executing you only have/need a single connection
(i.e. you don't need to reconnect every time you execute a query) no
matter where in your code you go.

That's how singletons work in PHP.

That's what I was afraid of. Kind of makes singletons worthless (at
least for my case), doesn't it? I could assign a new instance to a
variable and just reference that variable through the life of the
request. In the case of my (xml-based) config, I have to read the
config on every single request. I was hoping to avoid that without
using flat files or the session scope.

Am I missing another fundamental advantage of a singleton?

Thanks.

[Michael Fesser]

..oO(Rob Wilkerson)

>That's how singletons work in PHP.

That's what I was afraid of. Kind of makes singletons worthless (at
least for my case), doesn't it?

Partly. But they still assure that there's only a single instance to
work with, which is globally available from everywhere in your scripts.

>I could assign a new instance to a
variable and just reference that variable through the life of the
request. In the case of my (xml-based) config, I have to read the
config on every single request. I was hoping to avoid that without
using flat files or the session scope.

That's simply because of how PHP works:

init -request -response -done
init -request -response -done
....

To keep data available for several requests you would either need a real
application server:

init
request -response
request -response
....
done

which is not yet available for PHP (except for some experimental
projects) or you could have a look at shared memory.

Micha

[Rik Wasmus]

On Wed, 14 Nov 2007 16:10:53 +0100, Rob Wilkerson
<r.***********@gmail.comwrote:

On Nov 14, 9:25 am, ZeldorBlat <[e-mail]:

>>
That's expected. Remember that in PHP each request is independent of
the next. You'll only create one instance of your class /per request/
but it will be available everywhere you go.

Consider a database connection as an example. You open the connection
once per request, and you close it when the request is finished.
While the request is executing you only have/need a single connection
(i.e. you don't need to reconnect every time you execute a query) no
matter where in your code you go.

That's how singletons work in PHP.

That's what I was afraid of. Kind of makes singletons worthless (at
least for my case), doesn't it? I could assign a new instance to a
variable and just reference that variable through the life of the
request. In the case of my (xml-based) config, I have to read the
config on every single request. I was hoping to avoid that without
using flat files or the session scope.

Not really 'normal' PHP use, normally nothing should stay in memory after
a request. You could look into the shmop_* functionality though.
http://nl2.php.net/shmop
--
Rik Wasmus

[Jeremy]

Rob Wilkerson wrote:

On Nov 14, 9:25 am, ZeldorBlat <[e-mail]:

>That's expected. Remember that in PHP each request is independent of
the next. You'll only create one instance of your class /per request/
but it will be available everywhere you go.

Consider a database connection as an example. You open the connection
once per request, and you close it when the request is finished.
While the request is executing you only have/need a single connection
(i.e. you don't need to reconnect every time you execute a query) no
matter where in your code you go.

That's how singletons work in PHP.

That's what I was afraid of. Kind of makes singletons worthless (at
least for my case), doesn't it? I could assign a new instance to a
variable and just reference that variable through the life of the
request. In the case of my (xml-based) config, I have to read the
config on every single request. I was hoping to avoid that without
using flat files or the session scope.

Am I missing another fundamental advantage of a singleton?

Thanks.

If your XML config is complicated and you're worried about inefficiency
with loading it, have a look at memcached. You could store
configuration settings in memcached (although if your store the whole
configuration in one object it would have to be deserialized on each
request and would probably only be marginally faster than the XML).

Remember that disk access is probably not a huge bottleneck here. Trust
your operating system to keep that file in cache buffers :-) XML
processing is not exactly efficient, but no matter what you do you'll
probably be doing some kind of deserialization which is not really much
better. Even shmop functions will require you to deserialize some
string from the shared memory (and memcache is a lot simpler than shmop).

Regardless, I sincerely doubt that unless your app is a whole lot of
configuration and nothing else, loading the config on each request is
not going to introduce a noticable delay.

Jeremy

[Rob Wilkerson]

On Nov 14, 12:07 pm, Michael Fesser <[e-mail]:

.oO(Rob Wilkerson)

That's how singletons work in PHP.

That's what I was afraid of. Kind of makes singletons worthless (at
least for my case), doesn't it?

Partly. But they still assure that there's only a single instance to
work with, which is globally available from everywhere in your scripts.

Yeah, I guess I was sort of (illogically) hoping that singletons could
also manage to defy the fundamental nature of PHP and include a level
of persistence that would allow me to perform certain operations only
once. I suppose I just don't understand the concept of "globally
available from everywhere in your scripts" if a "new" instance is
actually being created with each request. If, somewhere between
requests, I alter my config then I could have one user using an old
version (until the next request) and another user using the new one.

I'd like to have more control over when the config is read so that I
can ensure that it's the only one in play at any given time, but the
config is loaded in a pseudo front controller, so it's not like I'll
ever encounter a condition under which it *doesn't* exist. That's
something, I guess.

Part of this is academic, too. It doesn't seem like much of a
singleton if I have to keep loading it over and over and if there's no
way for me to ensure that every user of my system is using precisely
the same configuration. Instead, each user is running their own fully
independent and fully functional instance of the "singleton" and
creating a new instance on each separate request. In a distributed
architecture more complex than what I need for this project, I suppose
the singleton-like nature could come in handy when using the same
instance in multiple components, but for my project its practical use
is limited.

Thanks for all of your help, guys. At least I have a better
understanding of the PHP runtime.

[Michael Fesser]

..oO(Rob Wilkerson)

>Yeah, I guess I was sort of (illogically) hoping that singletons could
also manage to defy the fundamental nature of PHP and include a level
of persistence that would allow me to perform certain operations only
once.

Nope, not out-of-the-box.

>I suppose I just don't understand the concept of "globally
available from everywhere in your scripts" if a "new" instance is
actually being created with each request.

OK. I just meant that you can easily access the singleton from within
every other function or method in your currently running script:

function foo() {
$obj = TMyClass::getInstance();
$obj->doSomething();
}

Wherever you need the singleton, you just have to call the getInstance()
method. It's like the 'global' keyword for importing global variables
into the local scope, but IMHO cleaner and more flexible. Of course the
next HTTP request is an entirely different thing and starts it all over
again.

>If, somewhere between
requests, I alter my config then I could have one user using an old
version (until the next request) and another user using the new one.

I'd like to have more control over when the config is read so that I
can ensure that it's the only one in play at any given time, but the
config is loaded in a pseudo front controller, so it's not like I'll
ever encounter a condition under which it *doesn't* exist. That's
something, I guess.

OK, understood. But in my own framework I load the current config on
every request. Even the user informations - if someone is logged-in -
are reloaded everytime to instantly reflect any changes (permissions for
example).

>Part of this is academic, too. It doesn't seem like much of a
singleton if I have to keep loading it over and over and if there's no
way for me to ensure that every user of my system is using precisely
the same configuration.

You would have to take care of that yourself if you really need it.
Currently there's nothing like an "application scope" in PHP like it is
in Java with an application server behind it. In PHP every HTTP request
is indepedent from each other, with all the benefits and drawbacks.

Micha

[Jerry Stuckle]

Rob Wilkerson wrote:

On Nov 14, 12:07 pm, Michael Fesser <[e-mail]:

>.oO(Rob Wilkerson)

>>>That's how singletons work in PHP.
That's what I was afraid of. Kind of makes singletons worthless (at
least for my case), doesn't it?

Partly. But they still assure that there's only a single instance to
work with, which is globally available from everywhere in your scripts.

Yeah, I guess I was sort of (illogically) hoping that singletons could
also manage to defy the fundamental nature of PHP and include a level
of persistence that would allow me to perform certain operations only
once. I suppose I just don't understand the concept of "globally
available from everywhere in your scripts" if a "new" instance is
actually being created with each request. If, somewhere between
requests, I alter my config then I could have one user using an old
version (until the next request) and another user using the new one.

I'd like to have more control over when the config is read so that I
can ensure that it's the only one in play at any given time, but the
config is loaded in a pseudo front controller, so it's not like I'll
ever encounter a condition under which it *doesn't* exist. That's
something, I guess.

Part of this is academic, too. It doesn't seem like much of a
singleton if I have to keep loading it over and over and if there's no
way for me to ensure that every user of my system is using precisely
the same configuration. Instead, each user is running their own fully
independent and fully functional instance of the "singleton" and
creating a new instance on each separate request. In a distributed
architecture more complex than what I need for this project, I suppose
the singleton-like nature could come in handy when using the same
instance in multiple components, but for my project its practical use
is limited.

Thanks for all of your help, guys. At least I have a better
understanding of the PHP runtime.

Rob,

One of the things you may be missing is that web pages are basically a
transactional request system. That is, the client calls a web page.
That page opens the resources it needs, fetches them and closes the
resources. The web page (transaction) then ends (and frees all resources).

The next page is another transaction and needs to do it's thing, also.

This is very different from batch programs which can keep resources
available across requests to the UI. Those are running all the time,
and can maintain resources across multiple requests.

It's a different style of programming, and if you're used to writing
batch programs, it takes a bit of getting used to the differences.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Rob Wilkerson]

On Nov 14, 11:25 pm, Jerry Stuckle <[e-mail]:

Rob Wilkerson wrote:

Rob,

One of the things you may be missing is that web pages are basically a
transactional request system. That is, the client calls a web page.
That page opens the resources it needs, fetches them and closes the
resources. The web page (transaction) then ends (and frees all resources).

The next page is another transaction and needs to do it's thing, also.

This is very different from batch programs which can keep resources
available across requests to the UI. Those are running all the time,
and can maintain resources across multiple requests.

It's a different style of programming, and if you're used to writing
batch programs, it takes a bit of getting used to the differences.

I'm familiar with the stateless nature of the web, but am admittedly
from a ColdFusion background where an application server was
involved. I could created a singleton and store it in the application
scope for persistence in memory and, in that way, ensure that I really
*was* returning the same instance. I'm learning. :-)

[Rob Wilkerson]

On Nov 14, 6:33 pm, Michael Fesser <[e-mail]:

.oO(Rob Wilkerson)

I suppose I just don't understand the concept of "globally
available from everywhere in your scripts" if a "new" instance is
actually being created with each request.

OK. I just meant that you can easily access the singleton from within
every other function or method in your currently running script:

function foo() {
$obj = TMyClass::getInstance();
$obj->doSomething();

}

Wherever you need the singleton, you just have to call the getInstance()
method. It's like the 'global' keyword for importing global variables
into the local scope, but IMHO cleaner and more flexible. Of course the
next HTTP request is an entirely different thing and starts it all over
again.

I guess what I keep coming back to is that this seems to have limited
practical use as a singleton. True, its instantiation becomes global
despite the fact that it may was instantiated (in your example) within
a traditionally scoped element (a function), but that seems like a
minor - and almost accidental - benefit. I don't tend to use
standalone functions that have no context, so scoping issues don't
really come up.

Additionally, my working practice is to use dependency injection
rather than create objects "on demand". That gives me a certain level
of controlled immutability. And, since the length of a request is so
short, it's usually pretty easy to feel reasonably secure that, during
the life of that request, an object instantiated in the "normal"
manner hasn't mutated to any kind of unusable (or unexpected) state
(perhaps I'm just naive?).

Anyway, I'm not trying to be difficult. Just trying to understand how
to best use singletons in a PHP context, their capabilities and their
limitations. You all have been a lot of help and I appreciate it.

[Jerry Stuckle]

Rob Wilkerson wrote:

On Nov 14, 6:33 pm, Michael Fesser <[e-mail]:

>.oO(Rob Wilkerson)

>>I suppose I just don't understand the concept of "globally
available from everywhere in your scripts" if a "new" instance is
actually being created with each request.

OK. I just meant that you can easily access the singleton from within
every other function or method in your currently running script:

function foo() {
$obj = TMyClass::getInstance();
$obj->doSomething();

}

Wherever you need the singleton, you just have to call the getInstance()
method. It's like the 'global' keyword for importing global variables
into the local scope, but IMHO cleaner and more flexible. Of course the
next HTTP request is an entirely different thing and starts it all over
again.

I guess what I keep coming back to is that this seems to have limited
practical use as a singleton. True, its instantiation becomes global
despite the fact that it may was instantiated (in your example) within
a traditionally scoped element (a function), but that seems like a
minor - and almost accidental - benefit. I don't tend to use
standalone functions that have no context, so scoping issues don't
really come up.

Additionally, my working practice is to use dependency injection
rather than create objects "on demand". That gives me a certain level
of controlled immutability. And, since the length of a request is so
short, it's usually pretty easy to feel reasonably secure that, during
the life of that request, an object instantiated in the "normal"
manner hasn't mutated to any kind of unusable (or unexpected) state
(perhaps I'm just naive?).

Anyway, I'm not trying to be difficult. Just trying to understand how
to best use singletons in a PHP context, their capabilities and their
limitations. You all have been a lot of help and I appreciate it.

I use them all the time. For instance, I might have a database class.
I might have several business classes which access tables in the
database. Each business class operates independently of the other
classes; I may use one or several in any once page.

The singleton class for the database means each of the business classes
can get the one instance of the database class. If the database object
doesn't exist, it is created and returned. If it does exist, it is just
returned.

Saves from having multiple connections to the database unnecessarily yet
business classes don't need each create their own classes, and the main
page code doesn't worry at all about the database.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Radek N.]

Rob Wilkerson pisze:

On Nov 14, 11:25 pm, Jerry Stuckle <[e-mail]:

>Rob Wilkerson wrote:

Rob,

One of the things you may be missing is that web pages are basically a
transactional request system. That is, the client calls a web page.
That page opens the resources it needs, fetches them and closes the
resources. The web page (transaction) then ends (and frees all resources).

The next page is another transaction and needs to do it's thing, also.

This is very different from batch programs which can keep resources
available across requests to the UI. Those are running all the time,
and can maintain resources across multiple requests.

It's a different style of programming, and if you're used to writing
batch programs, it takes a bit of getting used to the differences.

I'm familiar with the stateless nature of the web, but am admittedly
from a ColdFusion background where an application server was
involved. I could created a singleton and store it in the application
scope for persistence in memory and, in that way, ensure that I really
*was* returning the same instance. I'm learning. :-)

Maybe you should use Registry Pattern?
http://www.patternsforphp.com/wiki/Registry

--
Radek N.