[Zope-dev] singleton vs. utility (was Re: implementing zope.component 4.0)

Gary Poster gary.poster at gmail.com
Mon Nov 30 19:16:24 EST 2009


On Nov 30, 2009, at 5:21 PM, Fred Drake wrote:

> On Mon, Nov 30, 2009 at 5:14 PM, Lennart Regebro <regebro at gmail.com> 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


More information about the Zope-Dev mailing list