On Monday 15 November 2004 02:33 pm, Florian Gross wrote:
| trans. (T. Onoma) wrote:
| > On Monday 15 November 2004 01:23 pm, Florian Gross wrote:
| > | trans. (T. Onoma) wrote:
| > | > On Monday 15 November 2004 12:28 pm, Yukihiro Matsumoto wrote:
| > | > | I'd call them singleton classes.  Any objection?
| > | > |
| > | > |        matz.
| > | >
| > | > Yes, cause of singleton pattern.
| > |
| > | Objection to the objection: The singleton pattern is not widely used in
| > | Ruby. Couldn't we rename the implementation of it? Maybe something like
| > | "SingleInstanceClass"?
| >
| > Well, I just used it. And the rest of the OOP world knows Singleton, yes?
|
| What did you use it for and why would another name be a problem in your
| case?

In current project I use it for markup BaseAdapter Subclasses. In past I've 
used it for database pool, object pool, and CGI Singleton. There are others 
too that I can't recall off the top of my head.

I actually started a thread on this matter a few weeks ago, David brought up 
some good points. The nice thing about a singleton is that it is easily 
initialized. Pretty sure the implementation is also thread safe. Two big 
pluses in my book. Also, from a different vantage, singletons are nothing 
more than fully unique multitons. So are multitons also outmoded? And, if 
what you say is so, then what do other languages, lacking Ruby's proxy class, 
use in their stay? Should't such a "pattern" be common ground across OOPLs?

The problem I have is very simple: constant reoccuring confusion in 
discussions. Look back just a few post --it's even happened in this thread! 
And it was you who once again had to explain:

<quote>
Sorry, I was talking about the pattern that lets you only create a 
single instance of a class. See singleton.rb in Ruby's standard library.
</quote>

Don't you get tired of doing this? Honestly, I see this same kind of thing 
every time singleton comes up. There was a mention of singleton in the 
current DI thread, and guess what? I had no idea which one was meant. And 
changing the name of the module for Singleton to SingletonPattern or 
Pattern::Singleton is not going to help this problem at all.

Now, there is precedence for changing the name of singletons (the special per 
object class kind) in that they have been called othe things (even Ruby 
source code!), namely, meta class and virtual class. So the terminology is 
still wavering --hence our conversation. Of course there are also certain 
issues witht those two terms so something else would be prefereable. But in 
contrast, singleton, as in the pattern, is pretty well set in OOP stone 
(despite potential older Lisp usage). So why not just get on with it, change 
the name, and be done with the whole issue.

Once you start using it, it will become second nature in short order. Perhaps 
"trying it on for size" will help. Here's the relevant section of Pickaxe I 
using the term 'especial-class' (hyphenated) rather than potentially 
confusing term 'singleton class'.


Object-Specific Classes

Ruby allows you to create a class tied to a particular object. In the 
following example, we create two String objects. We then associate an 
anonymous class with one of them, overriding one of the methods in the 
object's base class and adding a new method.

a = "hello"
b = a.dup
class <<a
  def to_s
    "The value is '#{self}'"
  end
  def twoTimes
    self + self
  end
end
a.to_s  »  "The value is 'hello'"
a.twoTimes  »  "hellohello"
b.to_s  »  "hello"

This example uses the ``class << obj'' notation, which basically says ``build 
me a new class just for object obj.'' We could also have written it as:

a = "hello"
b = a.dup
def a.to_s
  "The value is '#{self}'"
end
def a.twoTimes
  self + self
end
a.to_s  »  "The value is 'hello'"
a.twoTimes  »  "hellohello"
b.to_s  »  "hello"

The effect is the same in both cases: a class is added to the object ``a''. 
This gives us a strong hint about the Ruby implementation: an especial-class 
is created and inserted as a's direct class. a's original class, String, is 
made this especial's superclass. The before and after pictures are shown in 
Figure 19.3 on page 242.

Ruby performs a slight optimization with these especial-classes. If an 
object's klass reference already points to an especial-class, a new one will 
not be created. This means that the first of the two method definitions in 
the previous example will create an especial-class, but the second will 
simply add a method to it.


T.