<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > >> <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >>> Yeah that's the same way that I implement it. You're still using >>> strings >>> for referencing class names. >> >> So what? Is there an alternative method? Does it have any advantages? > > Yes! Moving the singleton functionality into core php. Its an excellent > OOP feature.
Does such a feature exist in any other languages? What is the point of putting just one possible solution into core PHP when there are plenty of acceptable solutions already out there in userland? What is the problem with using strings to reference class names? It sounds like you want core PHP to change just beause there is a problem with your code. If you changed your code there would be no problem. -- Tony Marston http://www.tonymarston.net http://www.radicore.org >> >>> Sorry my file didn't get attached when sent to the list. >>> http://hlrally.net/media/singletonabc.inc >>> >>> The advantages are: >>> - Speed improvements >> >> Where is your proof? > > Think about it. You won't be calling upon php code every time you want > just to return an instance of a class. I'm sure APC (and others) could > run the usage code faster because they are given the ability to store a > class name rather than strings. > >> >>> - Allows for context sensitive code hinting in IDEs >> >> How is this of benefit? > > ... ! ... you must use a text editor such as vi or notepad... (not that > theres anything wrong with that) > >> >>> - Simplicity >> >> I disagree. My method is simpler and more intuitive than yours, and does >> not >> need any changes in core PHP. > > The only difference between my method > (http://hlrally.net/media/singletonabc.inc) and yours is that > - You have a local static variable for your table of instances > - You dont inherit from the singleton class > - You dont enforce a protected constructor (so multiple instances could be > created by noobs) > - You have some lame hack to translate the names of 3 of your classes to > files > - You allow for an argument to be passed to your constructor (usually > considered bad practise with singletons anyway) > > When I said simplicity, I was meaning using the native singleton method, > its easy for the programmer. They dont need to write their own singleton > management class (or research them on tutorial sites). And the usage > (accessing the singleton) can be made simpler as well. > >> >>> - Encourages good coding practices for amateur programmers >> >> I disagree. What is "good" to you is "not good" to others. There is more >> than one way of implementing the singleton pattern, (or any design >> pattern >> for that matter) so trying to enforce one particular method is just too >> short sighted for my taste. > > You can always still implement the variations using php. All Im proposing > is a simple mechanism for implementing single instance classes. I think > everyone needs to use this. > >> >> -- >> Tony Marston >> http://www.tonymarston.net >> http://www.radicore.org >> >>> >>> -----Original Message----- >>> From: Tony Marston [mailto:[EMAIL PROTECTED] >>> Sent: Saturday, 10 March 2007 9:55 PM >>> To: internals@lists.php.net >>> Subject: Re: [PHP-DEV] Native Singleton Implementation >>> >>> >>> <[EMAIL PROTECTED]> wrote in message >>> news:[EMAIL PROTECTED] >>>> 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:[EMAIL PROTECTED] >>>> Sent: Friday, 9 March 2007 11:39 PM >>>> To: internals@lists.php.net >>>> Subject: Re: [PHP-DEV] Native Singleton Implementation >>>> >>>> >>>> <[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 >>> >>> -- >>> 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
