Re: [Zope-dev] singleton vs. utility (was Re: implementing zope.component 4.0)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: > On Tue, Dec 1, 2009 at 01:16, Gary Poster wrote: >> I don't love "singleton." I think it is better than "utility." I agree at >> least that it probably isn't better enough to introduce confusion. I'd be >> more insistent on "singleton", or finding a better term than either of them, >> if this were a fresh API. > > I wonder if the best isn't to make the documentation clearly say > "Utilties are singleton components that can be looked up per > interface". +1 to improving the documentation. - -1 to using the term "singleton". The term is loaded up with things that aren't relevant to what utilities do: in particular, there is no requirement / promise that the object registered as a utilitiy is an instance of a class, much less that its class / module jumps through hoops to guarantee that only one instance can exist[1]. The promise is merely that the object returned from the lookup will provide the given interface: no more, no less. I have often registered functions as utilities, for instance, where the contract of the corresponding interface was just that it be callable with a given signature. I even recall registering a module as a utility, although I can't find the example at the moment. "Global objects" is a more accurate description of the things registered as utilities from ZCML / imperative code: even that term is inaccurate once persistent objects get registered. [1] See the description of the Singleton pattern in the mother-of-all-wikis: http://www.c2.com/cgi/wiki?SingletonPattern Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksVRvMACgkQ+gerLs4ltQ79/gCfbUH7gsgJT6yER0U/zBUxrT0E qzQAoKYOe6OnLRXs4bveRXST8Ogkxwj6 =eh4i -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] singleton vs. utility (was Re: implementing zope.component 4.0)
On Tue, Dec 1, 2009 at 01:16, Gary Poster wrote: > I don't love "singleton." I think it is better than "utility." I agree at > least that it probably isn't better enough to introduce confusion. I'd be > more insistent on "singleton", or finding a better term than either of them, > if this were a fresh API. I wonder if the best isn't to make the documentation clearly say "Utilties are singleton components that can be looked up per interface". -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
[Zope-dev] singleton vs. utility (was Re: implementing zope.component 4.0)
On Nov 30, 2009, at 5:21 PM, Fred Drake wrote: > On Mon, Nov 30, 2009 at 5:14 PM, Lennart Regebro wrote: >> True. For me utilities are tools. Like CMFs portal_whatever. But in >> Zope3 even small stupid singleton objects are utilities in some cases, >> and that is confusing for a beginner. > > I wonder how many typical Python programmers know the term > "singleton". Point taken, somewhat. That said, it's a term easily used on the Launchpad team at least. In contrast, I have to explain "utilities"...and, since "utility" means very little (Python is a utility from some perspectives), I use "a way to register and get singletons" as my explanation, which seems to work quite nicely. > Though it's not unusual for there to be exactly one > instance of a class in a process, it's pretty unusual to think about > that as a valuable aspect of a class. Which for the traditional > definition of singleton, it very much is. Point taken, somewhat. We don't have a single instance of a class. We have a single instance of an object providing an interface, in a given context (registry and "name"space at the moment). This is an extension of the idea of singletons, based on interfaces rather than classes. Similarly, classic adaptation is an extension of type casting, based on interfaces. To my mind, and in my explanations, what we actually use adaptation/multiadaptation for is an extension of class instantiation, based on interfaces to describe the output rather than classes. These comparisons are leaky, but these are all mostly leaky in the same, limited way: you replace classes with interfaces. I'm trying to solve a real-world problem: I have to explain these concepts to people who occasionally encounter them in the bowels of the software they write on a daily basis. I want the relevant API to take less time to explain, and to be easier to remember with limited exposure. Clearly tying the APIs and concepts to familiar ideas is a common approach to that problem. Whatever the solution, the *problem* sounds a lot to me like users of Grok and BFG, for instance. > -1 for calling utilities singletons, since that has nothing to do with > their usage. > > +1 for calling them utilities, since that has everything to do with > how they're used. I don't love "singleton." I think it is better than "utility." I agree at least that it probably isn't better enough to introduce confusion. I'd be more insistent on "singleton", or finding a better term than either of them, if this were a fresh API. Gary ___ 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 )
