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 https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
