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