RE: [PHP-DEV] Native Singleton Implementation

Yeah that's the same way that I implement it. You're still using strings for referencing class names. Sorry my file didn't get attached when sent to the list. http://hlrally.net/media/singletonabc.inc The advantages are: - Speed improvements - Allows for context sensitive code hinting in IDEs - Simplicity - Encourages good coding practices for amateur programmers -----Original Message----- From: Tony Marston [mailto:tony@marston-home.demon.co.uk] Sent: Saturday, 10 March 2007 9:55 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] Native Singleton Implementation <scott.mcnaught@synergy8.com> wrote in message news:001a01c762b8$805d6f60$0900a8c0@scottnote... > Hi Tony, > > I do have a single singleton class to deal with singletons (as you put > it). > I have attached it to this email for your reference. > > But it's back to my original problem where you either have to: > - Duplicate code for each singleton class ... or ... > - Reference your classes via strings (slower, stops code hinting from > working etc) I see no such problem with my implementation of a single class for singletons. > I use method two as you do and it is not nice. There is no nice way of > implementing singleton in php. I disagree. Take a look at http://www.tonymarston.net/php-mysql/singleton.html#global.helper.with.loade r > Have a full read of > http://bugs.php.net/bug.php?id=39946 > > Also, with three tiered architecture, there is even more reason to use > singleton. You have yet another layer, filled with classes that need only > be > instantiated once. I think as a developer that uses tiered architecture, > you would benefit greatly from this feature. I already have a more-than-adequate method of dealing with singletons (see http://www.tonymarston.net/php-mysql/singleton.html#global.helper.with.loade r) and I see absolutely no advantage in the method which you propose. Putting this into core PHP would be of no benefit to anyone. -- Tony Marston http://www.tonymarston.net http://www.radicore.org > Scott > > -----Original Message----- > From: Tony Marston [mailto:tony@marston-home.demon.co.uk] > Sent: Friday, 9 March 2007 11:39 PM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] Native Singleton Implementation > > > <scott.mcnaught@synergy8.com> wrote in message > news:001a01c75ffd$fa352520$0900a8c0@scottnote... >> 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:greg@chiaraquartet.net] >> Sent: Tuesday, 6 March 2007 4:12 PM >> To: toomuchphp-phpdev@yahoo.com >> Cc: scott.mcnaught@synergy8.com; '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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php