Rename singleton.rb to singletonpattern.rb and the module it implements from Singleton to SingletonPattern.
Alternatively, move it from singleton.rb to patterns/singleton.rb and implement the module as Patterns::Singleton (which would suggest that the third-party library Multiton would then become Patterns::Multiton and observer.rb becomes Patterns::Observer). The latter is a longer-term and more sustainable change, but is also more broad-spectrum.
Iterator.. If there is introduced a Pattern namespace, then I would have to place mine below it, so it then would become Pattern::Iterator::Collection. I cannot decide if I like or dislike the Pattern prefix.
About the Pattern filename suffix, then it would probably be better to turn it into a prefix, for instance pattern_observer.rb. Or maybe make a pattern subdirectory of lib. This way it would be easier to get an alphabetic listing of patterns.
-- Simon Strandgaard
Is it possible, that singleton.rb should be avoided, if we look at following facts:
Singleton means there is only one Object.
With singleton.rb there are two objects, once the <Class> object and again an object of <Class>, which can be accessed with <Class>.instance.
In GOF, there are listed 5 consequences of using the pattern:
1.-3. are the same with and without singleton.rb . 4. and 5. means, sometimes you decide to change from singleton to factory controlling the instance count.
So, if I want to change, I remove class << self and add a factory method to the class.
The main difference is the initialization of the Class object. Therefore, there have to be a pattern for only initializing once, like undefing the init method after calling it, which permits also an easy change to factory pattern. Also it have to be clear, when the initialization takes place, which is a bit strange with Singleton#instance, I find.Do i make some serious error in reasoning ? Is singleton.rb useful anymore, if we have an advanced class initialization scheme ?
-- Matthias Georgi
Matthias: I'm not sure that I understand what you're saying here. From a practical perspective, there is only a single instance with the use of Singleton (singleton.rb). The module Singleton provided by singleton.rb simplifies the implementation of making a GOF Singleton pattern object. Using Singleton, you simply do:
class MySingletonObject
include Singleton
end
MySingletonObject.new is made private and a new method MySingletonObject.instance is provided. As I understand it, there is the Multion pattern that should be as simple to implement (e.g., "include Multiton"). There is no removing "class << self" involved. I think that singleton.rb is still useful, but it needs to either be renamed or put into a different namespace. -- Austin
Well, what I meant, was
class MySingletonObject
singleton_class do
def initialize
end
end
initialize
end
As you see, this is simpler and does nearly the same.
class MySingletonObject
class << self
private :new
def instance
...
end
end
end
It has been a while since I've used singleton.rb, but it is not related to class << self (the singleton class object for the class of MySingletonObject). Quite honestly, I'm not seeing where you're going because of this. It is easier to tell people that they can make an object have one and only one instance by doing "require 'singleton'; include Singleton" in their class definition. -- Austin Ziegler
Matthias, if you run your code with this added:
m = MySingletonObject.new p m m = MySingletonObject.new p m
(and with your block version of singleton_class) you'll see that you're not actually doing the equivalent of Singleton. You can create two different instances of MySingletonObject.
I'm not sure whether there's a way to implement Singleton using singleton classes. I don't think it's necessarily important, though, especially if it's only done to make sense in retrospect of the coincidence of names. I think it's better to break the names out, as Austin suggests.
I was reading through my major backlog of ruby-talk archives and I found that points out that a proper singleton (ensuring only one instance of a class) could be used to control access to a database that doesn't do concurrency very well.
Also, to the anonymous poster before Zachary, thank you for saying what I was finding difficult to say. The Singleton Pattern is intended to restrict instance creation; the separate MySingletonObjects would actually have separate singleton classes. While the pattern could be generalised to a Pool of objects (with count 1), I think the case of one object and only one object is common enough to warrant Singleton. -- Austin Ziegler
I admit, I left something out, I just wanted to give a hint. To show a working example:
module Kernel
def singleton(&block)
s = class << self; self; end
s.class_eval(&block)
s.class_eval do
private :new, :allocate
def instance; self; end
end
initialize
end
end
class MySingleton
singleton do
def initialize
..
end
def hello
end
...
end
end
MySingleton.instance.hello MySingleton.hello
-- Matthias Georgi
IMO if Singleton is to be put into a module/namespace, it should be Antipattern::Singleton, not Pattern::Singleton. Blind use of the singleton pattern makes for code that is difficult to unit test, and I think unit tests are something the Ruby community would like to keep as one of its defining characteristics.
I also think that renaming singleton.rb or moving Singleton to a module solely to reduce confusion with the singleton class is a bad idea (since it will break existing code). Newcomers to Ruby come in with an idea of what "singleton" means already and so they will be confused when they see "singleton class" if it is not explained to them. It would be better to either clearly address this in a FAQ somewhere (explaining the difference between the two and why singleton class is a singleton of its own right), or start a movement to start writing metaclass instead of singleton class.
-- Paul Brannan
Back to RCRchive.
RCR Submission page and RCRchive powered by Ruby, Apache, RuWiki (modified), and RubLog