From: Florian Gross <flgr@...>
Date: 2004-11-19T00:28:16+09:00
Subject: Re: Kernel#singleton_class

trans. (T. Onoma) wrote:

> | > As for a constant, in a way that basically what one's doing. But the
> | > singleton also prevents any other instance of that kind. Granted in many
> | > cases that probably doesn't really matter. So sure I could probably just
> | > use a constant and not worry about the potential abuses. Of course I
> | > could also never bother to make a method private too. Maybe that's
> | > overstating it a bit, but the point is, there are always multiple ways of
> | > doing things. Singleton Pattern is just another tool, and if the shoe
> | > fits then where it. I don;t think we should throw it out just b/c it's
> | > easy to abuse.
> |
> | I guess your problem is that you are creating a class at all. Why don't
> | just assign a single Object to a constant and add methods to that single
> | object directly? (The   def obj.method() end  syntax makes this quite
> | convenient.)
> 
> Sure. One could do that, but it lacks for straightforward instantiation and 
> can't be subclassed. Since it amount to the about same thing, it just seems 
> easier to create a Singleton.

Subclassing is done by .dup()ing the Object and then adding new methods. 
I still don't know why you need "instantiation" (don't we usually 
instantiate with .new? -- Yet singleton.rb forces you to use .instance).

> | I'm still interested in how to do resource pools using Singletons.
> 
>   class MyPool
>     include Singleton
>     def initialize
>       @pool = {}
>     end
>     def [](key)
>       @pool[key]
>     end
>     def []=(key, thing)
>       @pool[key] = thing
>     end
>     # ...
>   end

I don't get why one needs "include Singleton" there -- it looks like it 
would make perfect sense to be able to have multiple pools. Are you sure 
you are not using a Singleton for making one single pool easily 
reachable from anywhere in your application? There's better alternatives 
for that.

> | > How about InfinityClass. Singletons can be immutable too.
> |
> | I think they should only be allowed to be immutable or else they lead to
> | very tight coupling. But I still wonder why you need a class when all
> | you want is a single Object anyway.
> 
> Like I said, pretty much the same thing. But take the above:
> 
>   class MySuperPool < MyPool
>     def add(key, thing)
>       raise "thing no good" unless thing.kind_of?(SuperThing)
>       @pool[key] = thing
>     end
>   end
> 
> Of course one could use a module and 'extend self' and so on, but again, why 
> go through the extras trouble?

Well, I'd rather use a Class in this context. Limiting the amount of 
Pools to 1 seems a bit arbitrary.

> | Still, I feel like "singleton class" is used more than the others. Maybe
> | you could grep #ruby-talk logs and compare the usage of the terms? (But
> | be sure to filter out the few occurrences of SingleInstanceClasses that
> | currently share the same name or the statistic will be slightly biased.)
> 
> How to access those logs?

Hm, sorry, I can not find an official site that has them. But I could 
package up my own local ones and mail them to you, if that is of help.

> | > The monotheistic doctrine of an OOP developer: God is Singleton.
> |
> | Most gods want you to believe that so that they can get power
> | exclusively. Having just one god will make it difficult to replace it by
> | a mock god when testing your believes.
> 
> LOL :) Test God? That'll be some interesting code.
> 
>   assert_divine(GodClass)
> 
> What kind of error message would you expect? A bolt of lightening? :)

Maybe a wide angle disintegration ray.