| > 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.
attr_accessor, *accessors)