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]

Re: Singleton design pattern relveance in PHP


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]

Re: Singleton design pattern relveance in PHP



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]

Re: Singleton design pattern relveance in PHP

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]

Re: Singleton design pattern relveance in PHP

In article <ioWdnS4b1twTYo HYRVnyrA@bt.com >, root@yourbox.co m 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