From: "trans. (T. Onoma)" Date: 2004-11-17T05:24:16+09:00 Subject: Re: Kernel#singleton_class On Tuesday 16 November 2004 09:18 am, Florian Gross wrote: | trans. (T. Onoma) wrote: | > | > | 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. | | Why don't use globals (or a constant) or a Module with module functions | instead? I don't understand how singletons are useful for pools however. | Could you explain? Well, with globals I can't control namespace. And modules have there one issues --like what if I change my mind? And not being able to subclass. 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 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? | | Multitons are however often immutable value objects meaning that they | can not be used as hidden global state. How about InfinityClass. Singletons can be immutable too. | > 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: | > | > | > 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. | > | > | > 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. | | Of course I'm tired of this. That's why I wanted to rename singleton.rb | into SingleInstanceClass. (Which explains what it does in simpler terms | than "Singleton" anyway.) It's just that the more common thing always | deserves the simpler and shorter name. Classes that can only be | instantiated once seem not to be useful enough (except as a way of using | globals without using globals in which case they are an anti-pattern) to | deserve this name. Of course this would be no problem if matz had | decided for one of the other alternatives -- but isn't "singleton class" | the term that is most commonly used already? Not substantially so. We've seen cases of the term virtual class. And I've seen the term metaclass at least as often --especially in libs. The monotheistic doctrine of an OOP developer: God is Singleton. T.