Inheriting class-based state


#1

This one puzzles me - I know there’s something fundamental that I’m not
understanding about Ruby’s object model. Consider these classes:

class Base
def self.my_name=(value)
@my_name = value
end
def self.my_name
@my_name
end
end

class Derived < Base; end

Base.my_name = ‘John’
puts Base.my_name
John

Derived.my_name
nil
Derived.my_name = ‘Mike’
puts Derived.my_name
Mike

So the class instance member @my_name isn’t inherited by the Derived
class.

How do I share state between a derived class and its base class?

Thanks
-John
http://www.iunknown.com


#2

@ means instance member variable
@@ means class member variable

Just change @my_name to @@my_name and you’ll be good to go.

David K.


#3

John L. wrote:

end
puts Derived.my_name
Mike

So the class instance member @my_name isn’t inherited by the Derived class.

That’s right. The #my_name and #my_name= methods are inherited, but when
you call them on Derived, they operate on the instance variables of
Derived.

How do I share state between a derived class and its base class?

Well, there are “class variables”, written @@my_name. But they can have
some surprising behaviors in current ruby(*), and in future ruby they
will not be shared up and down the inheritance hierarchy (they will only
be shared between a class and its instances).

An alternative:

class A
class << self
attr_accessor :__my_name

def my_name; A.__my_name; end
def my_name=(n); A.__my_name = n; end

end
end

class B < A
end

B.my_name = “fred”

p A.my_name # ==> “fred”

Or, if you don’t want __my_name polluting the namespace, you could use
this:

class A
class << self
def my_name; A.instance_variable_get(:@my_name); end
def my_name=(n); A.instance_variable_set(:@my_name, n); end
end
end

class B < A
end

B.my_name = “fred”

p A.my_name

The key difference between these two examples and your original attempt
is that, here, the “A” reference binds statically to the class A,
whereas, in the original code, the “@my_name” reference binds
dynamically to the instance on which my_name is called (which might
turn out to be A, or B or …).

HTH.

(*) search the archives–briefly, if you assign to a subclass’s @@x, and
then assign to the superclass’s @x you get two different variables.
Reverse the order of assignment, and there is only one variable:

irb(main):014:0> class A; end
=> nil
irb(main):015:0> class B<A; end
=> nil
irb(main):016:0> class A; @@x=1; end
=> 1
irb(main):017:0> class B; p @@x; end
1
=> nil
irb(main):018:0> class B; @@y = 2; end
=> 2
irb(main):019:0> class A; p @@y; end
NameError: uninitialized class variable @@y in A
from (irb):19
irb(main):020:0> class A; @@y = 3; end
=> 3
irb(main):021:0> class B; p @@y; end
2
=> nil


#4

Thanks, Joel - this is exactly what I needed to fix some ugliness in
RubyCLR.

I was trying to get class variables to work earlier, and actually ran
across
the problem that you mentioned in your (*). I just didn’t know it at the
time :slight_smile:

Cheers,
-John
http://www.iunknown.com


#5

On Sat, 13 May 2006, Joel VanderWerf wrote:

p A.my_name # ==> “fred”
one can just use traits for this:

harp:~ > gem install traits

harp:~ > cat a.rb
require ‘traits’
class A; class_trait ‘my_name’ => ‘fred’; end
class B < A; end

p A.my_name
p B.my_name

B.my_name = ‘joe’

p A.my_name
p B.my_name

harp:~ > ruby a.rb
“fred”
“fred”
“fred”
“joe”

voila - best of both worlds - shared and overridable values if
required.

-a