<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Hi Greg,
>
> There is no reason why you can't still use the current method to implement
> your variations to the singleton design pattern. But, yes, I am proposing
> that the strict "text book" variety is implemented.

There is no strict "text book" implementation of the singleton pattern. 
There are different implementations in different languages, so it is not 
possible to decide that one implementation is "pure" while all the others 
are "impure". My personal choice is to avoid a singleton method withn each 
class and have a single singleton class instead, thus avoiding a lot of code 
duplication.

> If you haven't had the need to singleton-ize more than 2-3 classes, you
> probably haven't worked with tiered architecture, or haven't thought to 
> use
> singleton in this situation.

I use a single singleton class which can instaniate any number of database 
table objects in my business layer, but I only have a single object in my 
data access layer. This object is instantiated from a class which is 
specific to the DBMS being used (MySQL, PstreSQL, or Oracle).

> The way I work is with two-tiered architecture.  I have a presentation 
> tier
> which consists of HTML and php which renders the HTML.  I then have a 
> second
> tier which is a data access tier.

The 3 Tier Architecture is better - presentation, business (domain) and data 
access - as it provides for a beter separation of responsibiities.

>  In the data access tier, I have one class
> for each database table.  In these classes there are SQL statements for
> saving, retrieving records, in fact any operation that I do to the table.
> No SQL resides outside of the table's data access class. Each one of these
> classes is a singleton.
>
> There are two things that a native singleton implementation would solve:
>
> - At the data access layer, it is nasty to duplicate the singleton pattern
> for each class, (or worse, work with strings for class names).
>
> - From the presentation layer, it is ugly to work with the data access
> singletons.
>
> Example: A page in the presentation tier which lists all news posts
>
> <?php foreach(getInstance('content_news_items')->getAll() as $post){ ?>
>
> <h1><?php echo($post['news_item_heading']) ?></h1>
> <p><?php echo($post[' news_item_contents']) ?></p>
>
> <?php } ?>
>
> It would be nicer (and much more efficient) to be able to go:
>
> <?php foreach(content_news_items->getAll() as $post){ ?>
>
> <h1><?php echo($post['news_item_heading']) ?></h1>
> <p><?php echo($post[' news_item_contents']) ?></p>
>
> <?php } ?>
>
>
>
> I actually have about 50 singleton classes in my current project, and 
> trust
> me, they are all warranted.

If you are complaining that your 50 singleton classes produces too much 
duplicated code, then your implementation is wrong. If you have a single 
class to deal wth singletons then there is no code duplication.

I do not think it is a good idea to implement a new "feature" into core PHP 
which serves no useful purpose other than to disguise inefficent coding 
practices.

-- 
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

>  I have put a copy of a screen shot of my
> eclipse project at: 
> http://hlrally.net/media/content_pages/gotsingleton.png
> I put a blue line next to the singleton classes.  The folder "components"
> represents the data access layer.  The presentation layer is not seen in
> that shot.
>
> Now we all have different programming styles and use different 
> architectural
> principles to each other.  Just remember this is not a debate about what
> architecture is better etc.  I am just showing an example.
>
> Scott
>
> -----Original Message-----
> From: Gregory Beaver [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 6 March 2007 4:12 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; 'Guilherme Blanco'; 
> internals@lists.php.net
> Subject: Re: [PHP-DEV] Native Singleton Implementation
>
> Peter Hodge wrote:
>> You should just need to:
>> - add T_SINGLETON to the parser.
>> - add an is_singleton flag for class definitions, activated by
> T_SINGLETON.
>> - overload the 'new' operator to retrieve from the hash table if the 
>> class
> is a
>> singleton (otherwise call __construct() as normal).
>> - implement some of those helper functions such as 
>> singleton_getobjects().
>
> Hi,
>
> This seems both to be excessively magical and inflexible.  For instance,
> I have implemented global singletons, singleton per-configuration path
> (i.e. for a configuration object with cascading configuration files, one
> singleton per configuration file location), and other models for
> singleton that stray on the continuum between singleton and factory.
> The proposed implementation allows only the textbook singleton.
>
> The benefit of having singleton in the zend engine in my book is zero.
> If you have 10 gazillion classes that are all singletons, perhaps
> another look at the design is in order?  I've never had to singleton-ize
> more than 2-3 classes in even the most complex projects I've been
> involved with.
>
> Greg
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to