Re: [Pythoncard-users] standardizing our use of singletons

Kevin Altis wrote:

> There are a number of classes in the framework implemented as singletons and
> they are done in a variety of different ways. If you don't already know what
> a singleton is and you follow the links below, you'll find out what they
> are.
> 
> Configuration (config.py), ObjectLookup and EventQueue (event.py), and Log
> (log.py) are all supposed to be singletons. There are probably other single
> classes in the framework, but a quick search of the yielded the ones above.
> 
> There is a Python Cookbook section dealing with singletons here:
> 
> http://aspn.activestate.com/ASPN/search?query=singleton&section=PYTHONCKBK&type=Subsection
> 
> I have to admit that the Borg recipe is appealing
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66531
> 
> I think it would be beneficial to standardize on one pattern for
> "singletons" and update the framework. Any preferences or suggestions?


Standardizing the way we implement Singletons sounds like a good idea.
I prefer to stay with traditional implementations of the GOF Singleton 
pattern.  The idea is not about sharing state, i.e. Borg, but providing 
a global access point to a single instance of a class.  The class is 
responsible for creation of instances, and is responsible for managing 
some resource ( log file, etc. ) .  For example, there should be one 
"log" in the system.  That log may write to one or many log files, or 
sockets, etc., and that can all be configured at runtime.  The user only 
needs to know about a single "log" instance.

Singleton is less brittle than say, defining module level functions in 
log.py , like log.info, log.warning, etc., even if those functions just 
call a single instance of the Log class.


> On a related note, the time has probably come for a generic util.py or
> misc.py module where we place our generic helper classes and functions used
> by other modules. I've already run into one or two import problems because
> of the readAndEvalFile function in res.py which is a generic helper function
> which needs to be taken out of res.py.

That sounds good.


> ka
> 
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 
> 
> 



-- 
Talk to ya,
Rowland

"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."

-- Bertrand Russell,
    quoted in the book
    A Word a Day