Re: Class Level inheritable attributes - are we there yet?

>
> Its rather difficult to believe we must in each case define / require
> our own custom module. Please note - i'm not complaining here. I just
> want to know whether the above example is "the best solution in use"
> for 1.8... 1.9....
>

you certainly aren't complaining and i must say that i'm a little
disappointed in the responses you are getting from people.

let me start out by saying that it is a *fact* that inheritable class
attributes are both useful and re-invented over and over.  do a search
on github, rubyforge, raa, google, and this mailing list and you will
find hundreds of examples.  github alone has 237 pages of results for
this search in many languages.  i'd also point out that there are
really two kinds of rubyists: those who write code for themselves and
those who write code for others.  if you systematically do searches
(on the same sources as above) for the people are against permutations
of class state vs. people are for it you will see a trend: people who
write lots of libraries (especially 'dsl-y' libraries) are in favor
of, and make heavy us of, class state of all kinds including
inheritable state - those who are against it are mainly writing their
own code and using other people's libraries.  the irony is that *most*
of the popular ruby libraries make use of inheritable class state:
just a short list

  . merb
  . ramaze
  . sqlite-ruby
  . main
  . couchrest
  . rubyigen
  . action_mailer
  . active_controller
  . active_record
  . extlib
  . facets
  . actionwebservice
  . active_support
  . zen test
  . fattr
  . etc...

so, if you like any of those libraries and what they have to offer,
you like class inheritable state being managed for you.  in addition
i'd point out that anyone who likes esoteric concepts like 'method
dispatch' or 'constant lookup' also likes auto-magically maintained
class state.  honestly it's tiresome to see this idea still being
debated on ruby-talk with buggy code and claims that rolling your own
inheritance is easy (it isn't - trust me - at least not in the general
case).  therefore i'd for one, as author of dozens of libraries which
have rolled their own class var inheritance, like to offer my support
of your plea: there absolutely should be a 'standard' method of doing
this.  i don't know if that means being in core or that it should be a
library (possibly distributed with core), but you are quite correct in
observing that one has to be careful mixing methods with common names
like 'inheritable' into Object etc.  a common, simple, and reusable
library would be a great help to many library writers and people that
claim that it wouldn't be obviously aren't writing a lot of libraries
- at least not certain types of libraries.

i'll leave you with my current favorite method of rolling class
inheritable attributes:


the fattr lib, avail as gem and at http://github.com/ahoward/fattr.
btw, anyone that thinks this is *easy* stuff should complete

  http://rubyquiz.com/quiz67.html

although some of the complete answers are terse they are *not*
simple.  the fattr code is based on the best answers.



cfp:~/src/git/fattr > cat a.rb
require 'rubygems'
require 'fattr'

class A
  class << A
    fattr(:x, :inheritable => true){ 42 }
  end
end

class B < A; end

class C < B; end


p C.x
p B.x
p A.x
puts

B.x = 42.0

p C.x
p B.x
p A.x
puts

C.x! # force re-initialization from parent(s)

p C.x
p B.x
p A.x
puts


class K
end
class L < K
end
module M
  fattr(:x, :inheritable => true){ 42 }
end
K.extend(M)

p L.x



cfp:~/src/git/fattr > ruby a.rb
42
42
42

42
42.0
42

42.0
42.0
42

42


regards.