Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:13734
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <418BB509.1080207@hristov.com>
Date: Fri, 05 Nov 2004 18:14:49 +0100
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041102
MIME-Version: 1.0
To:  Derrell.Lipman@UnwiredUniverse.com
CC: internals <internals@lists.php.net>
References: <is8k2su0.fsf@random.internal> <418BAA16.6020602@hristov.com> <u0s41atq.fsf@random.internal>
In-Reply-To: <u0s41atq.fsf@random.internal>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] new overloading feature?
From: php@hristov.com (Andrey Hristov)

Derrell.Lipman@UnwiredUniverse.com wrote:
> Andrey Hristov <php@hristov.com> writes:
> 
> 
>> Why not using Singleton for multiple objects with getInstance() ?
> 
> 
> Yeah, it's not quite a Singleton pattern.  I've seen references to what I'm
> talking about as a Pool pattern.  That's basically what I described here:
> 

Yes, Pool. I just said that it is Singleton for multiple objects which
in fact is pool.

>>>One could certainly call a function which searched for the key value and
>>>only instantiated a new object if the existing one was not found, but this
>>>seems cleaner.
> 
> 
> There are absolutely ways to do this purely at the application level.  It just
> seems that it'd be a really clean, easy to program, easy to understand
> methodology to pass the key value to the request for a new instance, and get
> back either a new instance, or a previously existing one with that key value.
> 
> In fact, the proposed __new() feature could provide an automatic Singleton
> capability without the caller needing to worry about (or even know) that it's
> dealing with a Singleton.  The class defines a __new() function that always
> returns its one and only instance (instantiating it the very first time), and
> the application can always use 'new' without worrying about the internal
> implementation.
> 
> Derrell
> 

The thing I find nice in the current way of implementing it with getInstance()
and a static class variable is that it is like it is defined in GoF. People
can easily understand what's going on. Otherwise it is too much of magic to me:)


Andrey