Re: Attempted roadmap of future instance variables....

Hi --

On Wed, 3 Dec 2003, Steve Tuckner wrote:

> So what is the relationship between @_ vars and @vars that are defined in a
> class context (if any)? Is this just to allow easier access to class local
> vars (that you can already define)? Does below describe the situation
> accurately?

I think that @_ and @ variables would behave identically when it came
to Class objects' instance variables -- simply because you can't
subclass Class, so the issue of whether the same or an old or new
variable is in use would never arise.  In other words, the situation
exactly analogous to what I did before would be:

  class Class
    def m
      @var = "hi"
      @_var = "hello"
    end
  end

  class B < Class      # error
    def n
      puts @var
      puts @_var
    end
  end

which can never happen.  

Also, I assume (and hope :-) that all of this will still be governed
by the "every object can have its own instance variables" principle.
That means that if an object is a Class, and has its own instance
variables, they will not be directly visible to other objects
(including instances of that class).

Therefore, in your example:

> class A
> 	@a = 1		# a is a class local variable
> 	@_a = 2		# a is also a class local variable
> 	@@a = 3		# a is a global variable whose visibility is itself and its
> sub-classes
> 
> 	def A.a		# define to allow access to class's instance var
> 		@a
> 	end
> 
> 	def display
> 		puts "a (class local - current) = #{self.class.a}"
> 		puts "a (class local - new) = #{@_a}"

@_a here would refer to the @_a of an instance of A, not A's own @_a.
And an instance of A, say 'a' in:

    a = A.new

is a different object -- a different 'self' -- from A, and therefore
does not have direct lexical access to A's own instance variables,
only its own.  

That, in turn, means you've asked it to display an uninitialized
instance variable, so here:

> A.new.display
> => a (class local - current) = 1
> => a (class local - new) = 2

you should get nil, not 2.  


David

-- 
David A. Black
[e-mail]