Simple (?) Singleton Question

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 '

Constructing

clearing...

Re: Simple (?) Singleton Question

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 '

Constructing

clearing...

Re: Simple (?) Singleton Question

On Nov 14, 12:04 am, 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 '

Constructing

clearing...

Constructing

Re: Simple (?) Singleton Question

On Nov 13, 6:04 pm, 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 '

Constructing

clearing...

Re: Simple (?) Singleton Question

On Nov 14, 9:25 am, ZeldorBlat wrote:
>
> 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.

Re: Simple (?) Singleton Question

..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

Re: Simple (?) Singleton Question

On Wed, 14 Nov 2007 16:10:53 +0100, Rob Wilkerson
wrote:

> On Nov 14, 9:25 am, ZeldorBlat wrote:
>>
>> 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

Re: Simple (?) Singleton Question

Rob Wilkerson wrote:
> On Nov 14, 9:25 am, ZeldorBlat wrote:
>> 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

Re: Simple (?) Singleton Question

On Nov 14, 12:07 pm, Michael Fesser wrote:
> .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.

Re: Simple (?) Singleton Question

..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

Re: Simple (?) Singleton Question

Rob Wilkerson wrote:
> On Nov 14, 12:07 pm, Michael Fesser wrote:
>> .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.
jstucklex@attglobal.net
==================

Re: Simple (?) Singleton Question

On Nov 14, 11:25 pm, Jerry Stuckle wrote:
> 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. :-)

Re: Simple (?) Singleton Question

On Nov 14, 6:33 pm, Michael Fesser wrote:
> .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.

Re: Simple (?) Singleton Question

Rob Wilkerson wrote:
> On Nov 14, 6:33 pm, Michael Fesser wrote:
>> .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.
jstucklex@attglobal.net
==================

Re: Simple (?) Singleton Question

Rob Wilkerson pisze:
> On Nov 14, 11:25 pm, Jerry Stuckle wrote:
>> 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.