Martin Aspeli wrote:
> For the record, I normally use the singleton analogy to explain unnamed
> global utilities. Perhaps that's bad, though I find it works pretty
> well. It'd probably be more accurate to use the terms you did, an
> "extension of the singleton principle", but as you say, it just adds
> more complexity.
> To me, the Singleton pattern says, "each time you ask for this, you get
> the same object". That's a little bit different from "this class can
> only be instantiated once". I think the important part of the design
> pattern is the shared instance (e.g. to conserve resources or to
> implement some kind of shared counting/tracking), not the restrictions
> on instantiation.
> I'm certainly -1 on using the term in the ZCA. I think changing our
> nomenclature would be terrible for the same reasons I think changing (as
> opposed to extending/improving) our API would be terrible. Utilities are
> in one way a more specific concept (due to the lookup semantics) and in
> another way a more generic concept (since named utilities can be used to
> implement a registry of homogenous objects).
To me the fact that an object "is" a singleton or a factory is
orthogonal to the registry stuff.
Why can't utilities be factories too that simply return themselves when
being called? Then being
a singleton or not would be in the responsibility of the registered
object (class, factory, singleton)
and the ZCA would not need to know.
What am I missing (except bbb)?
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -