Talk:Singleton pattern

message: Question: 
Is it true that when the only reference to the singleton is in the instance itself 
Garbage Collector might collect it? In my test it didn't happend which doesn't mean it never happens.
:No, this is not true.
Yes, the statement is true: For example, the following java program can demonstrate this:
public class Foo {
    public static void main(String[] args){
    Foo myFoo = new Foo();
        myFoo.selfReference = myFoo;
        PhantomReference<Foo> ref = new PhantomReference<>(myFoo);
        myFoo = null;
        System.gc();
        System.out.println(ref.isEnqueued());
    }
    Foo selfReference;
}
If running the program ever prints true, then that proves that the instance of Foo that was constructed was enqueued for deletion.
AJMansfield (talk) 21:24, 19 November 2013 (UTC)
replies: text:  In a singleton, the reference would be a static variable, not an instance variable. In Java classloaders keep strong references to all static variables they've loaded. Leem02 (talk) 02:41, 2 October 2016 (UTC)
thread_title:  Garbage Collection Reference 

message: Question:
Could someone include an example of how the Singleton is suppose to be used?
:The Singleton pattern should never be used. - Unsigned by 80.80.22.6
::A website's Session is a good example of a Singleton.--Wynler | Talk 14:18, 12 October 2007 (UTC)
replies: text: It might be used for that, but if the application is generic for more than one web site and runs in the same process (e.g in mod_perl, mod_python etc), it wouldn't work, because then they would all have the same Session instance. Unless what you want is truly *global*, you are likely to regret using the singleton pattern later on. Asksol | Talk 16:25 13 March 2008 (GMT+1)    —Preceding unsigned comment added by 213.236.208.22 (talk) 15:25, 13 March 2008 (UTC)
thread_title:  Example of Use? 

message: I fixed the implementation with a true lazy loading Singleton. Did it when was anonymous but hey. It's fixed. - Arch4ngel 19:38, 28 October 2007 (UTC)
replies: text: its worth fixing to me i care about it you dont have anything in it at all only i dont its my accomplishment my dream my hard work my blood sweat and tears . it makes me sick evil everyone that  has there hand in the destruction and torment of hurting and terrorizing gang stocking gaslighting me pure evil nothing good will every come to any of them because no of them are human  god will handle them all sad only for mr . 160.3.165.13 (talk) 12:21, 20 September 2023 (UTC)
thread_title:  Lazy Loading 

message: Check the links at the bottom and you'll find descriptions of why/when this may be used.  I don't think Wikipedia is the appropriate place to be assessing when and why something should be used.  The examples are already borderline appropriate in my opinion.  In fact, the only reason I even added the second example is frankly because the first one is a terrible example.
: Again, what's the problem this pattern seeks to resolve? The article says it's used when you only need one instance of a class. Well, that's not a problem in any programming language: Need one instance? Create one instance. No need for more? Create no more. So... is there really a problem this pattern resolves?
: If the answer's in the links,why isn't it in the article? I think it's more important for an encyclopedia to tell why is this needed than to show e.g. a posible implementation.
: --euyyn 02:23, 23 February 2006 (UTC)
thread_title:  That's what links are for 

message: The incorrect Java example is broken in that it is not incorrect. The object itself has no mutable state, and so does not suffer from threading issues.The second check is within the synchronized block, so there is no chance of more than once instance being created (per class-loader).
I suggest deleting rather than fixing the incorrect example. All it will be doing is confusing, and probably serving as a template for programmers who have not understood the issues.
BTW, very old versions of Sun's Java (like 1.0) did, apparently, garbage collect classes incorrectly. The spec now says that there is an implicit strong reference from class-loader instance to all of the classes it has loaded.
   Sorry but it is incorrect.  Please read any of the hundreds of references (one posted 
   in this article) to understand why.  Your assumption that it cannot create multiple 
   instances is wrong.
      > Sorry but it is incorrect.  Please read any of the hundreds 
      > of references (one posted in this article) to understand why.
      
      It is correct, as long as there is a second check inside the synchronized 
      createInstance() method!
      
:: Go to the Double-checked locking page if you want to argue this.  If you feel the need to contradict the many reliable, expert sources explaining why the exact thing you claim works does not, that's the place to do it.
      I have discussed this issue with some developers on my team:
      As far as we understand the issue (after reading Jeu George's blog as well as the 
      article by Peter Haggar of IBM linked there), the reason for the double-checked 
      locking to fail is *NOT* because the mechanism itself is at fault.
:: The Java memory model does not allow this to be reliable.  AS I understand it, if it did, it would severely limit JIT compilers ability to optimize bytecode.
      
      In fact it seems to be a severe bug in *some* JIT compilers:
      memory is allocated and assigned to the reference *before* the constructor of the
      object is executed!
:: As the JVM specification allows
      The lvalue of an assignment is *changed* before the right side has fully been evaluated!
      For details please refer to the article written by Peter Haggar.
      
      The compilers affected by this issue will most likely be causing way more severe 
      problems than this. String losing it's immutability (as mentioned by Haggar) being
      just one of the obvious ones.
      
      If this behaviour is actually violating the specs (which is something I am not going 
      to research on for now), then the double checked locking is *working*.
      
::It doesn't violate the specs.  The specs specifically allow this.
      In case the author of the two lines quoted above does still not agree on this, I
      would humbly ask for a reply - possibly more detailed than the usual "wrong! rtfm!".
      
      Best Regards, Felix Ehlermann, Senior Developer, Jenomics GmbH
:: Please read the double-checked locking page and the many sources explaining why double-checked locking does not work.  In almost all cases you can use staticly initialized singletons or initialize using an inner class.  The 1.5 memory model 'fixes' volatile so you can use that to fix double-checked locking but only on 1.5 and above.  Read this http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#dcl Dubwai 15:37, 23 June 2006 (UTC)
thread_title:  RE: Java code and double-checked locking 

message: This is NOT double checked:
 public class Singleton {
     private static Singleton INSTANCE = null;
 
     // Private constructor suppresses 
     private Singleton() {}
 
     //synchronized creator to defend against multi-threading issues
     private synchronized static void createInstance() {
             INSTANCE = new Singleton();
     }
 
     public static Singleton getInstance() {
         if (INSTANCE == null) createInstance();
         return INSTANCE;
     }
 }
"Double checking" requires a "check if null" then "synchronize" then "Check if null, agian" then "create."  Here is a double checked example:
 public class Singleton {
     private static Singleton INSTANCE = null;
 
     // Private constructor suppresses 
     private Singleton() {}
 
     //synchronized creator to defend against multi-threading issues
     private synchronized static void createInstance() {
         if (INSTANCE == null)
             INSTANCE = new Singleton();
     }
 
     public static Singleton getInstance() {
         if (INSTANCE == null) createInstance();
         return INSTANCE;
     }
 }
::You are right, the example was not double checked.  I have added the second check to the incorrect example.
:::Optimized the java code not to contain excessive volatile read. This article lacks the most effective way to obtain singleton which is thread local storage since it doesn't include memory barrier (or helper class that takes perm-gem space).  —Preceding unsigned comment added by Bestsss (talk) 23:33, 25 December 2008 (UTC)
replies: text:  Double checking is not a good way to implement a lazy singleton, far too much code. try a private static inner class Holder holding a final instance that is initialized on class load (of the inner class) and return that, and leave the rest to the java vm...
 public class Singleton {
     private static class Holder {
         private static final  Singleton INSTANCE = new Singleton();
     }
 
     // Private constructor suppresses 
     private Singleton() {}
 
     public static Singleton getInstance() {
            return Holder.INSTANCE;
     }
 }  — Preceding unsigned comment added by 83.231.170.196 (talk) 12:18, 16 July 2019 (UTC)
thread_title:  RE: Java code and double-checked locking 

message: While the Double Checked Locking (DCL) idiom works well in environments which have a well-defined memory barrier, DCL is generally accepted as an anti-pattern in Java because the Java Memory Model did not have such until JDK 5. While, as others have noted, DCL can be modified to work correctly in JDK 5 (or higher) environments, a better choice for the Java Singleton  implementation is the Initilization On Demand Holder idiom. The Initialization On Demand Holder idiom works in all Java environments, it performs well, and is a simple pattern to implement. See the following pages for the details:
  http://www.cs.wustl.edu/~schmidt/PDF/DC-Locking.pdf
  http://www.cs.umd.edu/~pugh/java/memoryModel/
  http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
  http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html
To help the Singleton article focus what a Singleton is and how it can be correctly implemented, I recommend the removal of the discussion how a Singleton can be incorrectly implemented in Java. A citation to the Double Checked Locking Idiom could be included, perhaps as a neutral reference or as an anti-pattern reference, and the DCL article could discuss or link to the DCL anti-pattern common in Java.
Jan Nielsen 18:12, 2 July 2006 (UTC)
replies: text:  Actually, I'd say the best way to implement it is via thread local storage (incl. ThreadLocal past java 1.4). Why: loading extra classes takes perm gem memory and involves extra IO operation + classloader sync (this is the very 1st time the singleton is created). Bestsss (talk) 23:40, 25 December 2008 (UTC)
thread_title:  Clarifying the Singleton Article 

message: I have added a new article called Initialization on Demand Holder Idiom which describes the idiom and provides an example in Java. Unless there are objections, I will change this article by removing the discussion on how not to implement a singleton to focus this article on what a Singleton is and how to implement it correctly. If there are objections, please post them here ASAP.
Jan Nielsen 16:07, 5 July 2006 (UTC)
thread_title:  Reference to Initialization on Demand Holder Idiom Article 

message: The non-thread-safe C++ example using the Curiously Recurring Template Pattern says that it's also known as the "Meyers Singleton" (after Scott Meyers, who apparently gave an implementation in More Effective C++). However, this Web-forum discussion is the only online source I can find for a "Meyers singleton" (other than Meyers' own website, which says he invented it but doesn't say what it is). And that forum discussion disagrees with our article — their "Meyers singleton" doesn't use the CRTP at all! Therefore, I have restored the  marker to that claim, and if it can't be verified in a few weeks, I'm just going to be WP:BOLD and delete the "Meyers" stuff. Someone who owns More Effective C++ might look it up. --Quuxplusone 04:09, 9 January 2007 (UTC)
replies: text: I've just removed the entire CRTP C++ example from the list of examples, thus making this question moot. As I noted in the section right above this one, it's pretty much irrelevant anyway, and it's not thread- or exception-safe. So, it's gone. (I'm not sure the novelty of the Ruby example makes up for its pedagogical uselessness, either...) --Quuxplusone 05:38, 15 January 2007 (UTC)
thread_title: Meyers singleton

message: I changed the class diagram because the underlines (They mean "static") are very important information for this pattern. --Trashtoy 03:04, 24 February 2007 (UTC)
thread_title:  About replacement of the class diagram 

message: It's also possible to use a function static variable instead of a class static one in PHP, which keeps things tidier IMHO:
 class Singleton {
   
   public static function getInstance() {
     static $instance;
     if (!$instance) $instance = new self;
     return $instance;
   }
   private function __construct() { /* Cannot create any more */ }
   private function __clone() { /* Cannot be cloned */ }
   
   // The rest of the class implementation goes here...
   
 }
 
 $instance = Singleton::getInstance();
Unfortunately there's currently no easy way to put this in a class that can be extended! (See comments of http://www.php.net/singleton for some ideas of ways around that limitation.)
--DaveJamesMiller 18:12, 4 March 2007 (UTC)
thread_title:  PHP Singleton without Class Static Variable 

message: In the Gang-Of-Four book, the singleton pattern is characterised by two requirements: one, restrict the instantiation of a class to one instance, and two, provide a global point of access to that instance. The article currently describes the first requirement but (as far as I can see) does not explicitly describe the second requirement. Is this intentional? — Tobias Bergemann 13:14, 5 March 2007 (UTC)
thread_title:  Global point of access for the singleton instance 

message: "Implementation
The singleton pattern is implemented by creating a class with a method that creates a new language has concurrent processing capabilities the method should be constructed to execute as a mutually exclusive operation."
The above does not seem to make any sense. I see an old edit that makes this nonsense change - the previous text does seem to make sense. Could someone who knows how change it back again - if the previous text is valid?
Davidmaxwaterman 04:01, 9 August 2007 (UTC)
thread_title:  nonsense 

message: Please add more inline citations. Shinobu 04:40, 2 September 2007 (UTC)
thread_title:  Citations 

message: I would suggest that this entry should contain some reference to the fact that the singleton is almost universally regarded as bad design.
Some minimal references for this point of view:
Why Singletons are Evil
Singleton Considered Stupid
Use your singletons wisely  —Preceding unsigned comment added by Swiftcoder (talk • contribs) 20:48, 11 November 2007 (UTC)
thread_title:  Singleton considered harmful? 

message: Why does the example create mutexes instead of using pthread_once? Bpringlemeir (talk) 20:12, 14 January 2008 (UTC)
thread_title:  C++ and pthread_once? 

message: Something should be added regarding the need to overwrite the clone method in java  —Preceding unsigned comment added by Lax4mike (talk • contribs) 16:14, 21 January 2008 (UTC)
thread_title: clone() method in java? 

message: why is it that static volatile is used for singleton and why not only static in java 1.5 example? What difference does that make?  —Preceding unsigned comment added by 210.210.79.19 (talk) 07:10, 19 February 2008 (UTC)
thread_title:  Question: why static volatile is used and why not only static in java 1.5 example? 

message: Warning: despite the claim "This is the only truly thread-safe implementation of a lazy-initialization of a singleton." below, the use of std::auto_ptr means that destruction is not correctly synchronised with construction, and therefore rules this out. RFST (talk) 14:47, 9 May 2010 (UTC)
thread_title:  C++ Pthread example is not Thread save either! 

message: This section has too many complications and does not provide a error free example, the memory is leaked., and we are associating Operating System specific things such as mutex, memory mapping etc., I think we must provide a simple example which will work irrespective of the Operating System, and irrespective of the primitives provided by the OS. I will try to provide a non-leaky Singleton example, and remove the current example, which is tied to OS and somewhat very confusing. Kindly review the changes. Thanks. — Nvineeth talk 17:54, 14 October 2008 (UTC)
replies: text: Hi, For the static initialization/deinitialization fiasco requires at least two global static vars, but in the example there is only one local static and in fact the current code is built on the lines of the solution for this problem,see Faq 10.13. I agree RAII is fine, but why unnecessarily create (and destroy) Lock objects, when one will do? Thanks. — Nvineeth talk 09:26, 23 October 2008 (UTC)
replies: text: Hi josh, yes, RIAA is definitely better, I did not read the "static" Mutex part in the previous example correctly so thought that there was bug., but when I check the older version, its perfectly fine. So it should be added back. Regarding the static init/deinit order fiasco, I dont think its applicable here, because it depends on how the singleton is implemented, and the one in the example does not depend on other static objects, nor is it global. — Nvineeth talk 10:46, 24 October 2008 (UTC)
thread_title:  C++ (using pthreads) 

message: I deleted this from the Common Uses section:
*Singletons behave differently depending on the lifetime of the virtual machine. While a software development kit may start a new virtual machine for every run which results in a new instance of the singleton being created, calls to a singleton e.g. within the virtual machine of an application server behave differently. There the virtual machine remains alive, therefore the instance of the singleton remains as well. Running the code again therefore can retrieve the "old" instance of the singleton which then may be contaminated with values in local fields which are the result of the first run.
because it is by no stretch of the imagination a Common Use, or any kind of Use. Come to that, neither is the point above it - but at least the point above it makes sense to the reader. This one does not: e.g. the reference to "the virtual machine", given that there's no reason to expect there to BE a virtual machine necessarily. I'm also not convinced that the point being made here is important enough or non-obvious enough to deserve to be in the article, which is why I didn't make the effort to find somewhere else in the article to put it.
Educres (talk) 11:52, 29 October 2008 (UTC)
thread_title:  Common uses section 

message: Someone has changed the contructor to protected, should be private instead.
=== CloneNotSupportedException ===
In Pugh's second Singleton class overriding clone() looks unnecessary to me. The example Singleton is derived from Object, which already does the job of throwing a CloneNotSupportedException. It only would be necessary if Singleton implements Cloneable, but then normally you would not throw a CloneNotSupportedException.
On the other hand, if you derive from a class that supports clone(), attempt to throw a CloneNotSupportedException produces a compile time error.
If i am wrong, please provide a reference at least, where people can find out the reason for this approach.
—Preceding unsigned comment added by 194.113.148.55 (talk) 12:48, 27 April 2009 (UTC)
thread_title:  The solution of Bill Pugh 

message: In Pugh's second Singleton class overriding clone() looks unnecessary to me. The example Singleton is derived from Object, which already does the job of throwing a CloneNotSupportedException. It only would be necessary if Singleton implements Cloneable, but then normally you would not throw a CloneNotSupportedException.
On the other hand, if you derive from a class that supports clone(), attempt to throw a CloneNotSupportedException produces a compile time error.
If i am wrong, please provide a reference at least, where people can find out the reason for this approach.
—Preceding unsigned comment added by 194.113.148.55 (talk) 12:48, 27 April 2009 (UTC)
thread_title:  CloneNotSupportedException 

message: Hi, long time user, first time contributor here. I think that the Obj-C sample code should be modified to what Apple recommends in their docs.
They have described their interpretation here:
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html#//apple_ref/doc/uid/TP40002974-CH6-SW66
And there is sample code here:
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/CocoaObjects.html#//apple_ref/doc/uid/TP40002974-CH4-SW32
However, I dare not edit the entry out of the blue as I don't want to step on anyone's toe.  —Preceding unsigned comment added by 130.225.195.131 (talk) 08:20, 24 March 2009 (UTC)
thread_title:  Objective C 

message: Can some one add something on how to destruct a singleton object? 
How/Why etc etc?? 
There is some discussion on this at "http://sourcemaking.com/design_patterns/to_kill_a_singleton"
Raoravikiran (talk) 09:03, 19 May 2009 (UTC)
thread_title:  Singeton Destructor: 

message: Isn't the following phrase a little bit too much oriented to a specific language ?
"Another notable difference is that static member classes cannot implement an interface, unless that interface is simply a marker. So if the class has to realize a contract expressed by an interface, it really has to be a singleton."
I think he is speaking about JAVA, because static members in some languages like C++ can inherit of a class only made of pure virtual method (which is an interface) and implement them through their class definition.
I think that it can be clearer to remove this part of the Implementation explanation, what do you think of that?
daminetreg 82.126.199.131 (talk) 14:59, 16 November 2009 (UTC)
thread_title:  Singleton Implementation 

message: It might be worth mentioning that Flash Actionscript doesn't really support true singletons (because the constructor of any class must always be public).  There are many ways to emulate it, though, and the example on this page is just that, an example of ONE way.  It is certainly not the DEFINITIVE way to do it (there being none).
--61.194.119.130 (talk) 07:45, 7 December 2009 (UTC)
thread_title:  Flash doesn't really support Singletons 

message: Is it worth mentioning Javascript in the prototype section? Many Javascript kids don't understand that the nature of the language and might come here looking. Sj26 (talk) 06:50, 1 February 2010 (UTC)
thread_title:  Javascript 

message: They are currently toy examples, something you learn once in class to learn its problems to never do it again. The last time I fixed it, someone said it was too complex for an encyclopedia entry, but I would at least like the caveats posted.
:I once solved Fermat's Last Theorem on the back of an envelope, but I don't remember where I've put it. (Read: talk is cheap.) RFST (talk) 18:54, 21 April 2010 (UTC)
replies: text: I'm so glad for you that you are competent while other people aren't. Are you also competent enough to substitute a solution that works? RFST (talk) 18:54, 21 April 2010 (UTC)

text: You vandal! RFST (talk) 18:54, 21 April 2010 (UTC)

text: How is that an argument for "bad"? With the same logic one might deduce that you're just "dumb". Not saying you are, but you should provide better arguments than throwing around words like "competent" (implying others aren't) or "obfuscated". RFST (talk) 18:54, 21 April 2010 (UTC)

text: Again, maybe not apparent to you, but if you want to differentiate between "without test" and "with test", writing the first version as "if (true)" makes for a more compact difference. What's "lazy" and "quick" about that? RFST (talk) 18:54, 21 April 2010 (UTC)

text: OK, this only makes sense to compare it with the non-thread-safe one, but to call this obfuscation is a bit much... You were definitely wrong about visibility, however: it's a private function. RFST (talk) 18:54, 21 April 2010 (UTC)

text: True. It's even worse, for thread synchronisation reasons. You missed that, didn't you! RFST (talk) 18:54, 21 April 2010 (UTC)

text: Well duh, this is pseudo code where you should substitute whatever applies to the platform under consideration, so this is beside the point. RFST (talk) 18:54, 21 April 2010 (UTC)

text: Eager construction in unreliable order disqualifies it in most situations. It has no significant added value over a simple global variable. RFST (talk) 18:54, 21 April 2010 (UTC)

text: So it's definitely a worse solution instead of a better one, or not even a solution at all. RFST (talk) 18:54, 21 April 2010 (UTC)
thread_title:  Current C++ examples 

message: The Delphi example needs the Assigned check in the shared destructor. If the instance is freed during runtime, an error will occur if the check is not there. Whoever removed it, please refrain from doing so again.  —Preceding unsigned comment added by Freddy1990 (talk • contribs) 10:25, 3 April 2010 (UTC)
thread_title:  Delphi example 

message: The current version characterizes the singleton pattern as a means of 'implementing the mathematical concept' of a singleton. I won't change it, but perhaps someone more knowledgeable than I am should? A singleton set is an extremely general concept, and it's not clear to me that this design pattern 'implements' this notion any more than does a bag with exactly one apple in it, say. Obviously, there is a connection between the two notions, and there is a good reason why the term 'singleton' is used here, but it seems to me the set-theoretic concepts are simply helpful in describing the design pattern, not something the pattern is intended to model. So, as I say, perhaps someone could either clarify the writing in an appropriate way? (That is, either in a way that addresses my concern, or, if I'm misunderstanding something, in a way that will discourage this misunderstanding in the future.) Thanks. MJM74 (talk) 06:34, 28 July 2010 (UTC)
thread_title:  'Mathematical concept of a singleton' 

message: I'm really confused at how this article got so bloated and complicated. Although I agree that as much detail should be given about the origin, concept and implementation of the Singleton pattern, I find that information about specific examples using the AbstractFactory pattern and the multiple language implementations should be removed. Wikipedia should not have 100 examples for each language for this simple pattern (if this were the case, this page would be even more unreadable than it is currently). I say simple because this is the first pattern I ever learned in classes (and I suspect it is common for everyone else too).
If it were up to me, this page would be 4-5 paragraphs, an example code in a strongly-typed, common programming language (i.e. Java) and the class diagram that is currently available. If people complain that there isn't 100 examples for each language, they should learn to program in that language before trying to use patterns in it.
If nobody opposes this, I might go and move the examples to another page for clarity's sake by the end of the week.  — Preceding unsigned comment added by Fuzzyrichie (talk • contribs) 04:34, 15 December 2010 (UTC)
thread_title:  Article too complicated 

message: Hello fellow Wikipedians,
I have just modified one external link on Singleton pattern. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20131002003845/http://www.javaexperience.com/design-patterns-singleton-design-pattern/ to http://www.javaexperience.com/design-patterns-singleton-design-pattern/
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 06:47, 6 December 2017 (UTC)
thread_title:  External links modified 

message: Hi All,
This article need a bit of rework. The existing Java example for lazy initialisation can be found in the article "Double-checked locking", as well as a much better example, as the current example here can be considered an anti-pattern.  — Preceding unsigned comment added by 83.231.170.196 (talk) 13:44, 17 July 2019 (UTC)
replies: text: Yup. I made an effort a while back, but it seems everyone is eager to turn this article into a "List of singleton implementations". Feel free to make an edit yourself, though I've concluded it's probably futile. Hpesoj00 (talk) 15:01, 29 June 2020 (UTC)
thread_title:  This article needs rework 

message: The Criticism section is full of imprecise information and based only on someone's opinion. Phrases such as "because a singleton can be accessed anywhere by anything without having to use any parameters" and "singletons are difficult to test because they carry global state for the duration of the program." are so wrong that I do not even know from where to start. There's a mix of different concepts and probably some language/own experience biases. A mark should be added to this section to warn about this.  — Preceding unsigned comment added by 82.131.59.214 (talk) 17:06, 2 November 2021 (UTC)
replies: text: I don't see anything wrong with this. Actually I believe the article in its current form is misleading since at least in the Design Patterns book by the Gang of Four, global accessibility of the singleton object is part of the definition of the pattern, I think. Or perhaps I misunderstand what you're saying. —Tea2min (talk) 11:35, 3 November 2021 (UTC)
replies: text: Agreed. The article is about Gang of Four singletons, and a GoF singleton "provide[s] a global point of access" and is "itself responsible for keeping track of its sole instance." That's very different from, e.g., a singleton lifetime in a dependency injection framework, where the class can be a POCO and not know anything about how it's used. Eeskildsen (talk) 18:40, 8 April 2022 (UTC)
thread_title:  Criticism