From: dblack@...
Date: 2006-04-11T02:02:46+09:00
Subject: Re: Adding in class attribute with a Module

Hi --

On Tue, 11 Apr 2006, zdennis wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> dblack@wobblini.net wrote:
>> Hi --
>>
>> On Tue, 11 Apr 2006, zdennis wrote:
>>
>>> James Britt wrote:
>>
>>
>> Actually I wrote this bit :-)
>>
>>>>
>>>>> I don't like the sprawl of the concept of
>>>>> an "attribute" of a class-hierarchy-plus-instances-of-those-classes.
>>>
>>>
>>> I think this is what you are referring to David, and I think it is
>>> strange to:
>>>
>>> zdennis@lima:~$ irb
>>> irb(main):001:0> class A
>>> irb(main):002:1>   @@myvar = 5
>>> irb(main):003:1>   class << self ; @myvar = 10 ; end
>>> irb(main):004:1> end
>>> => 10
>>> irb(main):005:0> A.instance_variables
>>> => []
>>> irb(main):006:0> A.class_variables
>>> => ["@@myvar"]
>>> irb(main):007:0> a = class A ; class << self ; self ; end ; end
>>> => #<Class:A>
>>> irb(main):008:0> a.instance_variables
>>> => ["@myvar"]
>>> irb(main):009:0> a.instance_eval "@myvar"
>>> => 10
>>> irb(main):010:0> A.module_eval "@@myvar"
>>> => 5
>>> irb(main):011:0>
>>>
>>> It seems like, @@myvar and @myvar should refer to the same reference
>>> point. I would expect @@ to signify a class level attribute, which
>>> is actually an instance attribute on the class itself. In my head
>>> that makes sense.
>>
>>
>> I disagree.  If @@myvar is just the instance variable @myvar of some
>> class object, then it would presumably have exactly the same scope as
>> that instance variable -- in which case, there's no reason for it to
>> exist.  If it's visible to other objects (i.e., when 'self' is
>> something other than the class object), then it isn't the same as an
>> instance variable anyway.
>>
>> I wouldn't want to see any crossover between class variables and
>> instance variables.  A class object's instance variables are strictly
>> the business of the class in its "civilian" capacity as a regular
>> object.  Class variables, on the other hand, are a special case.
>> The two things are really not related conceptually at all.
>>
>
> I see what you are saying, if there was crossover, then anything dealing with the class as an object, in it's "civilian" state as
> you put it would essentially become a class variable which it is not.
>
> On a implementation note, we achieve the same end result don't we (focus on the *end* part of that statement, and nothing in
> between)?
>
>  class C
>     class << self ; attr_accessor :m ; end
>  end
>
>  class D
>     def self.m ; @@m ; end
>     def self.m=arg ; @@m = arg  ; end
>  end
>
> - From a usage perspective as the end-user of the langauge nothing changes:
>
>  irb(main):025:0> C.m = 5
>  => 5
>  irb(main):026:0> C.m
>  => 5
>  irb(main):027:0> D.m = 10
>  => 10
>  irb(main):028:0> D.m
>  => 10

Sure -- it's just two ways to implement the method.  But I wouldn't
call the second one an attribute, because:

   class E < D
     @@m = 12
   end

so E (a different object from D) can directly, and without being
"impolite" (i.e., no instance_eval, etc.), manipulate the same
variable as the one storing the value in D.m.  And instances of D also
have direct, non-invasive access to that same @@m.

> It definitely seems that if the two are to stay separate by
> implementation and conceptualization that it would nice to have
> those class accessor methods, which don't invade the class's
> civilian state. I use that as a shortcut to writing my own
> accessors...
>   class << self ; attr_* :foo ; end
>
> Saves me typing in light of a class get/set shortcut existing...

I would actually expect something called cattr_* to work like that,
rather than the way the Rails one works.  Whether or not it's
necessary is another question :-)  But as a shortcut-shortcut, it
could make sense.


David

-- 
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" coming in PDF April 15, and in paper May 1!
http://www.manning.com/black