From: "David A. Black" Date: 2009-10-13T08:48:55+09:00 Subject: Re: Class Level inheritable attributes - are we there yet? On Tue, 13 Oct 2009, ara.t.howard wrote: > > >> >> 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 I'm puzzled by the divisive tone of this. I think we're all on the same side -- not necessarily of every topic that gets discussed here, but of the basic principle that we're all trying to help each other. In any case -- I'm not "against" class state. (I'm not even sure what that would mean.) I am conservative about use-cases, even important ones, making their way into the language as language-level constructs. That's what I've emphasized in this thread. I think too that you're conflating two distinct sub-issues: the creation of language-level constructs, and the phenomenon of rewriting the same code over and over. Obviously the latter is a bad idea, and no one in this thread is suggesting otherwise. If I say that Ruby can sustain a lot of quasi-language-feature-ish add-ons without having them be put in the language, that does not imply that these should be typed out by hand anew every time they're going to be used. David -- The Ruby training with D. Black, G. Brown, J.McAnally Compleat Jan 22-23, 2010, Tampa, FL Rubyist http://www.thecompleatrubyist.com David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com)