On Oct 19, 2007, at 10:22 AM, Rick DeNatale wrote:

> An interesting side note.  In Smalltalk, the declaration of variables
> doesn't initialize them.  Conventionally, class variables are
> initialized in a class method called initialize.  I'm a bit rusty on
> this but IIRC this is something which has to be done manually after
> defining the method and before instantiating any instances of the
> class.

hey rick - really good stuff.  i learned somethings smalltalk too.   
i'll keep this brief because i'm running out the door:  i've had at  
least two publicly released stabs and making reasonable class  
variable semantics.  this simples is attributes (gem install  
attributes) which gives you

class C
   attribute('title'){ "the #{ name.upcase }" }
end

class D < C; end

p C.title #=> 'the C'
p D.title #=> 'the D'

in which declaring the attribute does not initialize it - rather the  
block is stored and later instance eval'd for a lazy initialization.   
this gives a kind of 'initialize' step that is useful in some  
situations but it's only on a per attribute basis and it lacks the  
notion of inheritance.  for that i generally roll something custom like:



cfp:~ > cat a.rb
require 'attributes'

class C
   class << self
     attribute('a'){
       catch(:value){
         (ancestors - [self]).each do |ancestor|
           break unless self <= ancestor
           ancestor.module_eval{ throw :value, @a if defined? @a }
         end
         default = 42
       }
     }
   end
end

class D < C; end
class E < D; end
class F < E; end


p D.a

E.a = 42.0

p F.a



cfp:~ > ruby a.rb
42
42.0


which basically reads 'get your class variable from the first  
ancestor that has defined it'.  i've called this  
'inheritable_attribute' in some recent rails code but i'm not sure if  
it's a good name... i may add it to attributes but i've yet to decide  
if it's better to return '@a' or '@a.dup' - both have pros and cons...

i tackled this long ago with the traits lib too:

   http://codeforpeople.com/lib/ruby/traits/traits-0.9.2/README

but it's way too heavyweight for many purposes...

it's worth noting that both approaches create a different kind of  
inheritance that @@vars - which is far too unrefined for many use cases.

cheers.

a @ http://codeforpeople.com/
--
it is not enough to be compassionate.  you must act.
h.h. the 14th dalai lama