Yep, seems like an acceptable approach, it helps with brevity in the code,
since you can just say MySingleton doSomething instead of MySingleton current
doSomething.

Although where do you keep state?  Class-instance variables I suppose.

One potential bummer is if that singleton ever needs to be refactored to be a
non-singleton, there may be a lot of methods to move to the instance side as
well as a lot of code to change.  In that case, I suppose the rewrite tool
could help though..

I can't remember whether the GoF complained using the class as the singleton,
I'll have to check..

Cheers,
 Chris

--- Trygve Reenskaug <trygver at ifi.uio.no> wrote:

> Every class has an asociated singleton - the class object itself. The class
> of this object is, of course, its metaclass.
> 
> I have at times programmed singletons as a class object:
> 
> 1)Create a new class in the browser in the usual way, e.g.,
> SomeSingletonClass.
> 2)Then push the 'class' button to define the singleton's instance variables
> in the metaclass:
>      SomeSingletonClass class instanceVariableNames: 'foo ...'
> 3)Still in the class mode in the browser, I write and compile the class
> methods.
> 4) I can make sure nobody ever instantiates it or its subclasses by
> overriding basicNew with a diagnostic.
> 
> The singleton is now a global variable, #SomeSingletonClass.
> 
> Many people don't like this, but I see nothing wrong with it.
> 
> Cheers
> --Trygve
> 
> 
> 
> At 19:31 05.12.2005, you wrote:
> >Sounds like you want to do what MaSingleton does, declare "current" a
> >class-instance variable instead of a class variable.
> >
> >Then you don't repeat the #current method on all your singletons..
> >
> > > Message: 5
> > > Date: Sat, 03 Dec 2005 09:56:27 -0500
> > > From: rvclayton at acm.org (R. Clayton)
> > > Subject: Re: [Q] Why Squeak don't have a Singleton class ?
> > > To: The general-purpose Squeak developers list
> > >       <squeak-dev at lists.squeakfoundation.org>
> > > Message-ID: <87wtim1b6s.fsf at UlanBator.myhome.westell.com>
> > > Content-Type: text/plain; charset=us-ascii
> > >
> > >
> > >   We could have:
> > >
> > >   Object subclass: #Singleton
> > >      instanceVariableNames: ''
> > >      classVariableNames: 'UniqueInstance '
> > >      poolDictionaries: ''
> > >      category: 'Kernel-Classes'
> > >
> > >   current
> > >      UniqueInstance ifNil: [UniqueInstance := Singleton basicNew].
> > >      ^UniqueInstance
> > >
> > >   new
> > >      self error: 'Use current to get an instance of Class ' , self name
> > >
> > > I'm not understanding how this would work as a superclass.  current
> should
> > > return the object of one of Singleton's child classes, not the object
> > of the
> > > Singleton class (which shouldn't exist anyway given that Singleton
> > should be
> > > an
> > > abstract class).  Because I don't know of a simple way of calling down an
> > > inheritance hierarchy, I'm thinking that Singleton>>current can best be
> > > implemented as a subclass responsibility, which runs counter to factoring
> > > common code in a superclass (or suggests that there may not be a useful
> > > amount
> > > of factorable common code among singleton implementations).
> > >
> > >   In case not, why not
> > >
> > > Assuming the previous objection can be dealt with, the need for a class
> > > variable per singleton class causes a problem.  For example, if I make
> both
> > > SymbolTable and TypeTable subclasses of Singleton, then the return
> > value for
> > > both SymbolTable>>current and TypeTable>>current is set by whichever of
> > > SymbolTable>>current or TypeTable>>current is called first, an unhappy
> > event
> > > for the current method called second.
> > >
> > > There's a few ways to fix this.  One is move UniqueInstance down into the
> > > child
> > > classes too, at which point we can end the discussion as to why there's
> no
> > > Singleton class in Squeak (assuming there isn't one; I don't know for
> > sure).
> > > Another is to implement a registry of Singletons (Design Patterns, page
> > 130),
> > > which is a loss if you're interested in making code simpler and smaller.
> 
> 
> --
> 
> Trygve Reenskaug      mailto: trygver at ifi.uio.no
> Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
> N-0378 Oslo           Tel: (+47) 22 49 57 27
> Norway
> 
> 
> 
>