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@acm.org (R. Clayton) Subject: Re: [Q] Why Squeak don't have a Singleton class ? To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Message-ID: 87wtim1b6s.fsf@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.
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@acm.org (R. Clayton) Subject: Re: [Q] Why Squeak don't have a Singleton class ? To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Message-ID: 87wtim1b6s.fsf@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.
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@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@acm.org (R. Clayton) Subject: Re: [Q] Why Squeak don't have a Singleton class ? To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Message-ID: 87wtim1b6s.fsf@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@ifi.uio.no Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver N-0378 Oslo Tel: (+47) 22 49 57 27 Norway
Just to have given my 2 cents: often beginners tend to see and code singleton classes everywhere, however in most cases this is not necessary or even too restricting for future extensions in the architecture. Personally I try to avoid Singletons whenever possible, in my opinion it should not be used and is a code-smell in itself.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
squeak-dev@lists.squeakfoundation.org