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  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to