OpenStruct#update?

[T_Onoma]

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.

···

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?

[David_A_Black3 (David A. Black)]

Hi --

I am curious how I can capture a block that was passed. Here's what I'm
trying to do:

class BaseClass
  def initialize( arg1 )
    puts "got a block" if block_given?
  end
end

class SubBaseClass < BaseClass
  def initialize( arg1 , arg2 )
    super( arg1 )
  end
end

sbc = SubBaseClass.new( "aarg1" , "arg2" ) { puts "my block" }

I would like BaseClass to receive the block I passed to the SubBaseClass
  constructor. I have tried a few variations, but nothing went.

It involves '&'s:

  class BaseClass
    def initialize(arg1)
      puts "got a block" if block_given?
      yield
    end
  end
  
  class SubBaseClass < BaseClass
    def initialize(arg1, arg2, &block)
      super(arg1) &block
    end
  end
  
  sbc = SubBaseClass.new( "aarg1" , "arg2" ) { puts "my block" }

David

···

On Tue, 16 Nov 2004, Zach Dennis wrote:

--
David A. Black
dblack@wobblini.net

[Nobuyoshi_Nakada]

Hi,

At Tue, 16 Nov 2004 12:13:51 +0900,
Zach Dennis wrote in [ruby-talk:120510]:

I am curious how I can capture a block that was passed. Here's what I'm
trying to do:

class BaseClass
  def initialize( arg1 )
    puts "got a block" if block_given?
  end
end

class SubBaseClass < BaseClass
  def initialize( arg1 , arg2 )
    super( arg1 )
  end
end

sbc = SubBaseClass.new( "aarg1" , "arg2" ) { puts "my block" }

I would like BaseClass to receive the block I passed to the SubBaseClass
  constructor. I have tried a few variations, but nothing went.

Your code prints "got a block". "super" passes the given block
to the super class'es method, unless called with &nil.

# Please stop posting by replying to irrelevant threads.
# Otherwise I sometimes tend to miss new threads you posted.

···

--
Nobu Nakada

[Robert]

"David A. Black" <dblack@wobblini.net> schrieb im Newsbeitrag
news:Pine.LNX.4.44.0411160209190.26196-100000@wobblini...

>
> "Florian Gross" <flgr@ccan.de> schrieb im Newsbeitrag
> news:2vsa7rF2ot432U1@uni-berlin.de...
> > trans. (T. Onoma) 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"?
>
> But this will have more impact on existing code. I vote for

conservative

> behavior here: leave Singleton as it is and invent a good name for the
> method that returns TCFKASC (who will guess this? Ruby quiz #13.5...

:-))

The Class Formerly Known As Singleton Class. What do I win?

Ooops, that was too fast. Must - make - up - prize...

You win a virtual pad on the shoulder combined with a virtual fanfare:
Tataaaaaa!

    robert

···

On Tue, 16 Nov 2004, Robert Klemme wrote:
> > > On Monday 15 November 2004 12:28 pm, Yukihiro Matsumoto wrote:

[Zach_Dennis1 (Zach Dennis)]

Thanks a million!

Zach

David A. Black wrote:

···

Hi --

On Tue, 16 Nov 2004, Zach Dennis wrote:

I am curious how I can capture a block that was passed. Here's what I'm trying to do:

class BaseClass
def initialize( arg1 )
  puts "got a block" if block_given?
end

class SubBaseClass < BaseClass
def initialize( arg1 , arg2 )
  super( arg1 )
end

sbc = SubBaseClass.new( "aarg1" , "arg2" ) { puts "my block" }

I would like BaseClass to receive the block I passed to the SubBaseClass constructor. I have tried a few variations, but nothing went.

It involves '&'s:

  class BaseClass
    def initialize(arg1)
      puts "got a block" if block_given?
      yield
    end
  end
    class SubBaseClass < BaseClass
    def initialize(arg1, arg2, &block)
      super(arg1) &block
    end
  end
    sbc = SubBaseClass.new( "aarg1" , "arg2" ) { puts "my block" }

David

[Florian_Gross]

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?

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.

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.

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?

[David_A_Black3 (David A. Black)]

Hi --

···

On Tue, 16 Nov 2004, Zach Dennis wrote:

Thanks a million!

See Nobu's response, though -- your code already worked But the
&-technique for capturing blocks is worth knowing about too.

David

--
David A. Black
dblack@wobblini.net

[T_Onoma]

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:
>
> <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.

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.

···

On Tuesday 16 November 2004 09:18 am, Florian Gross wrote:

[Florian_Gross]

trans. (T. Onoma) wrote:

> 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.

It depends:

   $colors::red # => "red"
   $colors::blue # => "blue"
   $colors::green # => "two colors ought to be enough for everyone"

where:

   $colors = Module.new do; extend self
     define_method("red") { "red" }
     define_method("blue") { "blue" }
     define_method("green"){"two colors ought to be enough for everyone"}
   end

I'm pretty sure I could also come up with a syntax that makes it feel more natural.

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.)

I'm still interested in how to do resource pools using Singletons.

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.

> 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.

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.)

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.

···

On Tuesday 16 November 2004 09:18 am, Florian Gross wrote:

[T_Onoma]

trans. (T. Onoma) wrote:
> > 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.

It depends:

   $colors::red # => "red"
   $colors::blue # => "blue"
   $colors::green # => "two colors ought to be enough for everyone"

where:

   $colors = Module.new do; extend self
     define_method("red") { "red" }
     define_method("blue") { "blue" }
     define_method("green"){"two colors ought to be enough for everyone"}
   end

I'm pretty sure I could also come up with a syntax that makes it feel
more natural.

Cute. Never thought of using globals in that manner before --but I guess one
might as well use a module in such case.

> 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.

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

  # else where ...

  mp = MyPool.instance

> 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?

> > 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.

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?

> 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?

T.

···

On Wednesday 17 November 2004 11:53 am, Florian Gross wrote:

> On Tuesday 16 November 2004 09:18 am, Florian Gross wrote:

[Florian_Gross]

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.

[T_Onoma]

trans. (T. Onoma) wrote:
> 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).

Give me a prototype-based OOPL, baby! Yes, I dislike using #instance usually,
and have changed it to #new before. If you do that an interesting consequence
arises --you can force all one's code to use the same instance irregardless.
(Although I don't know how useful that is in practice, but it's interesting
nonetheless.)

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.

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

Yes. You could Of course. The idea is that there should be one and one of
these pools. But perhaps that is unnecessarily enforced, and docs can specify
"USE THIS CONSTANT".

> > 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.

Getting back to the earlier notion. This is basically what I decided. In my
lib I created Object#special_class and aliased #singleton_class to it. In the
future I will refer to it as the "special singleton" or "singleton
special-class".

> > > 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.

Oo.. that'll hurt!

Laters,
T.

···

On Thursday 18 November 2004 10:28 am, Florian Gross wrote: