While the described approach is valid there is a caveat if the script library defining the singleton is loaded from multiple sources at the same time. Because of this the described approach, all though nice, doesn’t really solve the real problem with creating singletons in LotusScript. It is my opinion impossible to create a real singleton in LotusScript without resorting to document based synchronization, if the same script library is loaded from multiple sources at the same time.
The problems stems from the fact that all scripts are running within their own little memory space making it impossible to share memory between different instances of the same script.
The reason I am quite sure of this is that I spent considerable amounts of time in vain a month or so ago trying to do this. I needed to write a simple transaction manager for NotesDocument objects so that documents that were reserved where automatically rolled back if the calling document wasn’t saved.
Due to application requirements the active form had to have an embedded view showing the documents that had been checked out and hence was under “transaction control”, but since the LotusScript code in the embedded view would have no way of knowing when the document containing the embedded view was saved, the script library with the transaction manager needed to be loaded (Use’ed) from both the form and the embedded view. Using a real singleton should solve this problem just fine, but due to the LotusScript memory model this approach created two “singletons” which kinds of defied the point.
A simple way to demonstrate this behaviour is to have the singleton compute to unique value (e.g. @Unique) in its constructor and have it output the unique value at each method invocation. This way you would see two different singletons performing operations.
The solution was to have the transaction manager synchronize its state with an user-specific profile document before and after each operation. The performance of this approach is quite okay.
So be aware of this kind of behavour when creating singletons that may be loaded from multiple scripts at the same time.