From: Ruby Admirer <ruby_admirer@...>
Date: 2007-02-09T21:31:23+09:00
Subject: Re: What is really a class instance variable compare to a class variable ?

--0-1687865825-1171024231=:140
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Brian, David,
   
  Thanks a lot for your replies.
  It's now crystal clear for me.
   
  David,
   
  Your book is excellent !
  May be you can add these additional explanations in a next revision :-)!
   
  CM.

dblack@wobblini.net wrote:
  Hi --

On Fri, 9 Feb 2007, Ruby Admirer wrote:

> David,
>
> Thanks a lot for your reply. But this raises another understanding problem for me. It seems that regarding inheritance there are different behaviours for :
> - an object instance variable
> - a class variable
> - a class instance variable

You've got two very different things there:

- instance variables
- class variables

Instance variables all behave alike. Class variables are completely
different, and unrelated. It's best not to go into it expecting any
similarity.

> For the following code (I'm running Ruby 1.8.5p12) :
>
> class TestObject
> def initialize
> @var = "an object instance variable"
> end
> def print
> puts @var
> end
> end
> class DerivedTestObject < TestObject
> def set_var
> @var = "an object instance variable : changed"
> end
> end
>
> o = DerivedTestObject.new
> o.print
> o.set_var
> o.print
>
> The output is :
> an object instance variable
> an object instance variable : changed
>
> => So, an object instance variable is shared/seen by the derived
> object instances.

Not exactly. Every object has its own instance variables, which are
not seen by any other object. Your DerivedTestObject instance
executes the initialize method, and inside that method, its instance
variable @var is initialized. In set_var, that variable is changed.

The fact that initialize is defined in a superclass doesn't mean
anything. When initialize is executed, 'self' is the new
DerivedTestObject instance. So @var, when it appears in that method,
belongs to that instance.

It's better always to think of instance variables in terms of what
object is 'self' at the moment the instance variable appears. An
instance variable has no knowledge of class or inheritance; it only
knows 'self'.

> For the following code :
>
> class TestClass
> @@var = "a class variable"
> @var = "a class instance variable"
> def self.print
> puts @@var
> puts @var
> end
> end
> class DerivedTestClass < TestClass
> def self.set_var
> @@var = "a class variable : changed"
> @var = "a class instance variable : changed"
> end
> end
> TestClass.print
> puts "-------------"
> DerivedTestClass.print
> puts "-------------"
> DerivedTestClass.set_var
> DerivedTestClass.print
> puts "-------------"
> TestClass.print
>
> The output is :
> a class variable
> a class instance variable
> -------------
> a class variable
> nil
> -------------
> a class variable : changed
> a class instance variable : changed
> -------------
> a class variable : changed
> a class instance variable
>
> => So, a class variable is shared/seen by derived classes (similar
> behaviour as an instance variable). Conversely, a class instance
> variable is not shared/seen by derived classes.

No instance variable is shared with any other object. TestClass and
DerivedTestClass are two different objects; therefore, they do not
share instance variables. Again, instance variables have no concept
of "class" or "inheritance". They simply adhere to the object in
whose context as 'self' they are created.

> Am I missing something ?
>
> Another question :
> The inheritance of a class variable and a class method is really great :-).
> Is it going to be removed in Ruby 2.0 ? I heard something about
> that but I hope not.

My current understanding is that class variables will be visible only
to the class or module they're defined in, including instance methods
of that class or module. I have mixed emotions about this. I would
actually rather see them disappear. My experience over the years is
that they cause more confusion than they're worth, and that in 2.0
they're going to be *almost* like instance variables of class objects
but not quite... and therefore people are still going to wonder what's
going on and why it has to be there. (At least, I will :-)


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)



 
---------------------------------
Need a quick answer? Get one in minutes from people who know. Ask your question on Yahoo! Answers.
--0-1687865825-1171024231=:140--