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

[Kevin A. <al...@se...>]

> 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.

But the effect of the Borg pattern is the same since all the instances share
the same state there is only one effective log, or at least that is how it
is described.

> 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.

I guess the question is whether we are likely to subclass any of the
singleton classes? That seems unlikely with config or log.

> > 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.

Okay, so do we use the dreaded generic util.py? My requirement for this
module is that it is standalone and won't import other modules in the
framework, causing a loop like res importing util, util importing res.

ka