Singleton design pattern relveance in PHP

[Bit Byte]

Since the webserver loads a PHP script every time a request is issued
from a client, it seems that Singletons are unnessesary in PHP?, since
each time an object is invoked, it is (guaranteed?) to be the only
instance - at least for that thread that is handling the request ? No ?

If I am missing something quite obvious, please let me know.

[ZeldorBlat]

Bit Byte wrote:

Since the webserver loads a PHP script every time a request is issued
from a client, it seems that Singletons are unnessesary in PHP?, since
each time an object is invoked, it is (guaranteed?) to be the only
instance - at least for that thread that is handling the request ? No ?

If I am missing something quite obvious, please let me know.

<?php
//Thread starts

$a = new Foo();
$b = new Foo();

//Now have two instances of Foo, all in the same thread -- no
guarantees here

//Thread ends
?>

[Bit Byte]

ZeldorBlat wrote:

Bit Byte wrote:

>>Since the webserver loads a PHP script every time a request is issued
from a client, it seems that Singletons are unnessesary in PHP?, since
each time an object is invoked, it is (guaranteed?) to be the only
instance - at least for that thread that is handling the request ? No ?

If I am missing something quite obvious, please let me know.

<?php
//Thread starts

$a = new Foo();
$b = new Foo();

//Now have two instances of Foo, all in the same thread -- no
guarantees here

//Thread ends
?>

Hmm, yes, that was a rather obvious refudiation of the point I was
making. I obviously wasn't making myself clear. What I meant was to say
was that other than in cases (such as the one above) where the user
deliberately creates multiple instances of the same class, I can't see
the relevance of porting this Pattern to PHP - since each request is
handled in a new thread/(possibly) process.

Case in point. I have wrapped up all of my user management functionality
in a usermanger class which derives from a Singleton base class
(following logic I had used in my C++ program). Its only when I started
using this class that it became obvious to me that the logic was not
necessarily meaningful in the PHP space - each request to manage a user
- will (as I understand it) - fork a new process (or maybe just spawn a
new thread), which will have its own singleton class - blisfully unaware
of the other's existence - unless ofcourse - the Singleton objects are
being cached in shmem (shared memory) - otherwise, it all seems a bit
like a pointless exercise in futility (because in C++ etc, once you
create a Singleton, it notmally stays memory resident until program
termination - whereas in PHP, the Singleton is only alive for the
duration of the request?) - unless again, I am missing something.

[Oli Filth]

Bit Byte said the following on 29/09/2006 12:13:

ZeldorBlat wrote:

><?php
//Thread starts

$a = new Foo();
$b = new Foo();

//Now have two instances of Foo, all in the same thread -- no
guarantees here

//Thread ends
?>

Hmm, yes, that was a rather obvious refudiation of the point I was
making. I obviously wasn't making myself clear. What I meant was to say
was that other than in cases (such as the one above) where the user
deliberately creates multiple instances of the same class, I can't see
the relevance of porting this Pattern to PHP - since each request is
handled in a new thread/(possibly) process.

If you're not the only user of your class, then the example code above
is entirely possible. Remember that the whole point of a lot of OOP
semantics is purely to enforce design rules - e.g. public vs. private,
abstract, final, etc. In other words, forcing your users to use your
code as it was designed.

Another scenario might be something like the following contrived scenario:

$objects = array();

foreach ($requests as $item)
{
switch ($item)
{
case ITEM_FOO:
$objects[] = Foo::createFoo();
break;

case ITEM_BAR:
$objects[] = Bar::createBar();
break;
}
}
}

Where $requests is an array containing "requests" for creation of Foo
and Bar objects, which are then collected in the $objects array. In
this scenario, if we only want a single shared instance of Bar, for
instance, we would need to design it as a singleton.

Of course this is contrived, but it demonstrates that situations where
multiple requests for an instance are not necessarily as simple as
ZeldorBlat's example above.
--
Oli

[Klaus Brune]

In article <io********************@bt.com>, ro**@yourbox.com says...

>

ZeldorBlat wrote:

Bit Byte wrote:

>Since the webserver loads a PHP script every time a request is issued
from a client, it seems that Singletons are unnessesary in PHP?, since
each time an object is invoked, it is (guaranteed?) to be the only
instance - at least for that thread that is handling the request ? No ?

If I am missing something quite obvious, please let me know.

<?php
//Thread starts

$a = new Foo();
$b = new Foo();

//Now have two instances of Foo, all in the same thread -- no
guarantees here

//Thread ends
?>

Hmm, yes, that was a rather obvious refudiation of the point I was
making. I obviously wasn't making myself clear. What I meant was to say
was that other than in cases (such as the one above) where the user
deliberately creates multiple instances of the same class, I can't see
the relevance of porting this Pattern to PHP - since each request is
handled in a new thread/(possibly) process.

Case in point. I have wrapped up all of my user management functionality
in a usermanger class which derives from a Singleton base class
(following logic I had used in my C++ program). Its only when I started
using this class that it became obvious to me that the logic was not
necessarily meaningful in the PHP space - each request to manage a user
- will (as I understand it) - fork a new process (or maybe just spawn a
new thread), which will have its own singleton class - blisfully unaware
of the other's existence - unless ofcourse - the Singleton objects are
being cached in shmem (shared memory) - otherwise, it all seems a bit
like a pointless exercise in futility (because in C++ etc, once you
create a Singleton, it notmally stays memory resident until program
termination - whereas in PHP, the Singleton is only alive for the
duration of the request?) - unless again, I am missing something.

How about if we take the discussion outside of pure code and into the
real world... I don't know if this will be applicable to a "pure"
singleton pattern as defined in a class. However...

Let's say you have a system where a user logs in, and from that point
you're using sessions to manage the log-in state. Would you allow the
user to say, log in using two or three different web browsers installed
on the same machine? Or (potentially) worse, let them give their log-in
information to friends and co-workers?

Would code that prevents this sort of thing qualify as something that is
attempting a singleton pattern? Say, by checking user_agent, or not
allowing a log-in when the user is already logged in?

Just a bit of wool-gathering, and my 2 cents.

GC