Jeffrey Moss
7/11/2005 10:47:00 PM
David,
To clarify, what I meant by a subclass slot is accessors that point to a new
class instance variable in *each* subclasses, whereas a class slot points to
the instance varaible in the class that the class slot was defined in.
Here is an example to illustrate:
class A
subclass_attr_accessor :subclass_slot
class_attr_accessor :class_slot
end
class B < A; end
class C < A; end
b = B.new
c = C.new
b.class.subclass_slot = 1
b.class.class_slot = 2
p c.class.subclass_slot # nil
p c.class.class_slot # 2
c.class.subclass_slot = 3
p b.class.subclass_slot # 1
bb = B.new
p bb.subclass_slot # 1
-Jeff
----- Original Message -----
From: "David A. Black" <dblack@wobblini.net>
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>
Sent: Monday, July 11, 2005 4:27 PM
Subject: Re: class_attr_accessor
> Hi --
>
> On Tue, 12 Jul 2005, Jeffrey Moss wrote:
>
>> I was playing around with class variables and class instance variables
>> because I wanted to implement a certain functionality, while not really
>> understanding the coexistence of the two, I found the reason the two
>> exist is quite clear, the class instance variables facilitate "subclass
>> slots" (as I know them from other languages) while the @@ syntax
>> facilitates "class slots"
>
> I'm not sure what you mean (but I'm not familiar with the term
> "subclass slot"). If a class object has instance variables, there are
> no implications for the subclasses:
>
> class A
> @x = 1
> end
>
> class B < A
> p instance_variables # []
> end
>
> This is really just because instance variables are per-object, so the
> instance variables belonging to the object A are of no concern to
> any other object (including B). But, again, I'm not sure I'm getting
> what you meant about subclasses.
>
>> I did a google search for "class_attr_accessor" and found that a number
>> of people have implemented this functionality in their own code. I
>> suggest it be officially added to the ruby distribution.
>>
>> Here is an example:
>>
>> class Module
>> private
>> def class_attr_accessor(*attrs)
>> attrs.each {|attr|
>> module_eval(<<-EOS)
>> class << self
>> def #{attr}; @#{attr}; end
>> def #{attr}=(v); @#{attr} = v; end
>> end
>> EOS
>> }
>> end
>> end
>>
>> I really don't think a new notation, similar to @@, is necessary, I think
>> calling obj.class.accessor_name is very nice. In fact having both a
>> subclass_attr_accessor and a class_attr_accessor wouldn't hurt either. In
>> that case, class_attr_accessor would just be a way to make @@vars public.
>
> I'm still not sure where subclasses come in; they're different
> objects, so they have different instance variables. Also, class
> variables (@@var) aren't part of the whole attr_* and instance
> variable universe, so I don't think you'd want to have a method with
> an attr_* name that dealt in class variables. It would just get
> confusing.
>
> Actually I would say not only is a new notation not necessary for
> class instance variables, but a new method isn't either :-) What we
> sometimes call "class instance variables" are not a separate
> language-level construct. They are simply instance variables which
> happen to belong to a Class object. The object (like any other
> object) can choose to expose them, keep state in them, etc.
>
> Consider these two examples:
>
> class C
> class << self
> attr_accessor :x
> end
> end
>
> some_string = "I am a string"
> class << some_string
> attr_accessor :y
> end
>
> In both cases, I've created an accessor for an object. One is a Class
> object (C); one is a String object (some_string). But I don't expect
> there to be a class_attr_accessor or string_attr_accessor method. I
> just get myself into the right scope (with the class keyword), and
> then I call attr_accessor. Classes are not special cases in this
> context.
>
> In both cases, too, the accessors will be implemented using instance
> variables (since that's how attr_* works). The fact that C is a Class
> object does not change this, one way or the other: there's no
> involvement of different variables (such as @@var), and there's no
> *more* involvement of other objects (such as instances or subclasses
> of C) than there is in cases where the object gettings accessorized is
> not a Class.
>
>
> I think it can be useful to use the term "class instance variable" in
> cases where someone might mistakenly think that you're talking about
> an instance variable of instances of a class, and you want to clarify
> that that's not what you mean. But it's actually not a separate
> construct, and attr_* works the same for Class objects as for other
> objects. I would personally be opposed to introducing the appearance
> of a difference into the language.
>
>
> David
>
> --
> David A. Black
> dblack@wobblini.net
>