Why do I want 1.8.2?

ruby-talk
1

Sorry for the silly question, but I just installed 1.8.2-preview2 on my
OS X laptop and I cannot find release notes or a summarized change log.

It would be nice if someone could explain the major differences between
1.8.1 and 1.8.2 in a few lines.

S.

2

There is a ChangeLog file in the source dir you built 1.8.2p2 from.

···

On Nov 2, 2004, at 11:53 AM, Stefan Arentz wrote:

Sorry for the silly question, but I just installed 1.8.2-preview2 on my
OS X laptop and I cannot find release notes or a summarized change log.

It would be nice if someone could explain the major differences between
1.8.1 and 1.8.2 in a few lines.

3

I think that will be done when 1.8.2 is actually released.

-austin

···

On Wed, 3 Nov 2004 04:53:47 +0900, Stefan Arentz <stefan.arentz@gmail.com> wrote:

Sorry for the silly question, but I just installed 1.8.2-preview2 on my
OS X laptop and I cannot find release notes or a summarized change log.

It would be nice if someone could explain the major differences between
1.8.1 and 1.8.2 in a few lines.

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

4

There is a ChangeLog file in the source dir you built 1.8.2p2 from.

There is a ChangeLog file in the source dir you built 1.8.2p2 from.

That's all well and good if you want to wade through 7600 lines of
changelog. I don't think he (nor I) was looking for every CVS entry
detailing each and every way eval.c was changed over the last year.
This information is useful if you are actively developing/debuging
Ruby, but he wants to USE Ruby. So, the question is, what are the
*major* bug fixes and new features in 1.8.2? (I want to know also)

5

consider the following two classes:

class Foo1
  attr_accessor :data
  include Singleton
end

class Foo2
  def data
    return @@data
  end

  def data=(val)
    @@data = val
  end
end

in irb screen:

[mkhan@localhost mkhan]$ irb
irb(main):001:0> require 'singleton'
=> true
irb(main):002:0> class Foo1
irb(main):003:1> attr_accessor :value
irb(main):004:1> include Singleton
irb(main):005:1> end
=> Foo1
irb(main):006:0> a = Foo1.instance
=> #<Foo1:0xf6fc4d4c>
irb(main):007:0> b = Foo1.instance
=> #<Foo1:0xf6fc4d4c>
irb(main):009:0> a.value = 100
=> 100
irb(main):010:0> p b.value
100
=> nil
irb(main):011:0> class Foo2
irb(main):012:1> def value
irb(main):013:2> return @@value
irb(main):014:2> end
irb(main):015:1> def value=(val)
irb(main):016:2> @@value = val
irb(main):017:2> end
irb(main):018:1> end
=> nil
irb(main):019:0> a = Foo2.new
=> #<Foo2:0xf6fe0cb8>
irb(main):020:0> b = Foo2.new
=> #<Foo2:0xf6fdcf00>
irb(main):022:0> a.value = 100
=> 100
irb(main):023:0> p b.value
100
=> nil

in both class we will have single instance of 'data'.
Which one is better and why?
Can someone explain it, please.

Thanks in advance... :slight_smile:

···

--
Mohammad

6

Mohammad Khan wrote:

consider the following two classes:

class Foo1
  attr_accessor :data
  include Singleton
end

class Foo2
  def data
    return @@data
  end

  def data=(val)
    @@data = val
  end
end

in irb screen:

[mkhan@localhost mkhan]$ irb
irb(main):001:0> require 'singleton'
=> true
irb(main):002:0> class Foo1
irb(main):003:1> attr_accessor :value
irb(main):004:1> include Singleton
irb(main):005:1> end
=> Foo1
irb(main):006:0> a = Foo1.instance
=> #<Foo1:0xf6fc4d4c>
irb(main):007:0> b = Foo1.instance
=> #<Foo1:0xf6fc4d4c>
irb(main):009:0> a.value = 100
=> 100
irb(main):010:0> p b.value
100
=> nil
irb(main):011:0> class Foo2
irb(main):012:1> def value
irb(main):013:2> return @@value
irb(main):014:2> end
irb(main):015:1> def value=(val)
irb(main):016:2> @@value = val
irb(main):017:2> end
irb(main):018:1> end
=> nil
irb(main):019:0> a = Foo2.new
=> #<Foo2:0xf6fe0cb8>
irb(main):020:0> b = Foo2.new
=> #<Foo2:0xf6fdcf00>
irb(main):022:0> a.value = 100
=> 100
irb(main):023:0> p b.value
100
=> nil

in both class we will have single instance of 'data'.
Which one is better and why?
Can someone explain it, please.

Thanks in advance... :slight_smile:

It is difficult (though not impossible) to do initialization code on a class. For instance, with the Singleton include, you can have a constructor that does one-time initialization on the instance:

   class Foo
     include Singleton
     def initialize
       ...
     end
   end

   f = Foo.instance

To do the same thing with a class-based singleton would require you to do some less-intuitive initialization magic.

- Jamis

···

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

7

Hi --

consider the following two classes:

class Foo1
  attr_accessor :data
  include Singleton
end

class Foo2
  def data
    return @@data
  end

  def data=(val)
    @@data = val
  end
end

in irb screen:

[mkhan@localhost mkhan]$ irb
irb(main):001:0> require 'singleton'
=> true
irb(main):002:0> class Foo1
irb(main):003:1> attr_accessor :value
irb(main):004:1> include Singleton
irb(main):005:1> end
=> Foo1
irb(main):006:0> a = Foo1.instance
=> #<Foo1:0xf6fc4d4c>
irb(main):007:0> b = Foo1.instance
=> #<Foo1:0xf6fc4d4c>
irb(main):009:0> a.value = 100
=> 100
irb(main):010:0> p b.value
100
=> nil
irb(main):011:0> class Foo2
irb(main):012:1> def value
irb(main):013:2> return @@value
irb(main):014:2> end
irb(main):015:1> def value=(val)
irb(main):016:2> @@value = val
irb(main):017:2> end
irb(main):018:1> end
=> nil
irb(main):019:0> a = Foo2.new
=> #<Foo2:0xf6fe0cb8>
irb(main):020:0> b = Foo2.new
=> #<Foo2:0xf6fdcf00>
irb(main):022:0> a.value = 100
=> 100
irb(main):023:0> p b.value
100
=> nil

in both class we will have single instance of 'data'.

Do you mean 'value' rather than 'data'?

Which one is better and why?
Can someone explain it, please.

I think you'd probably make the decision to use Singleton based
primarily on the question of whether you really need the "only one
instance" thing.

If you just need a way to maintain state in a class that doesn't mix
in Singleton, you have several choices:

1. a class variable. At the moment (Ruby 1.8), class variables are
not strictly class-scoped; they are shared by subclasses. This is
scheduled to change, so that they are truly class-scoped.

2. an instance variable of the class. This is really the purest way
to do it, I think. What you're doing is basically allowing
the Class object to behave like a regular Ruby object -- which it is.
The downside is that it can be mildly awkward to set up accessor
methods, should you want them:

   class C
     def C.var; @var; end
     def C.var=(x); @var = x; end
   end

or
   class C
     class << self
       attr_accessor :var
     end
   end

Then you can do:

   class C
     def some_method
       x = self.class.var
       # etc.
     end
   end

3. Maybe a constant or class method would be sufficient -- or maybe
not, but I thought I'd list them too :slight_smile:

David

···

On Fri, 5 Nov 2004, Mohammad Khan wrote:

--
David A. Black
dblack@wobblini.net