From: Dreamcat Four Date: 2009-10-13T22:21:13+09:00 Subject: Re: Class Level inheritable attributes - are we there yet? Tom Stuart wrote: >> else. > Isn't this covered by the below? Not sure how class level attributes > would give an advantage in this case. Writing the analogy out in Ruby isn't much help here. The construct you are showing is just the familiar method-based and pattern is a method for performance reasons that you should prefer it. We don't argue that point. However by employing such the constructor chain, the species/class definition is entirely static and not part of it can ever change. Its brittle and fragile, and cannot adjust to / survive with changing conditions in its environment. Of to put it another way - you cannot append or overload a constructor funtion at runtime without destroying entirely destroying the original constructor definition. In Ruby, a class is defined as an object and therefore is free to change its attributes over time. So there's no barrier in the Ruby language to say "you must define your attributes wholely in the constructor and only ever in the constructor function". The real problem we are trying to address is that for the Library writer, who will write a library of objects that behind it shall use the constructor paradigm for many thing. But there are just a few things which are sitting behind that in some stateful resource. (and are used by, say 60% all object). To represent some stateful resource (endpoint which may or may not exist) in such a brittle and inflexible way is problematic. Essentially the constructor paradigm forces you to return to method-based and functionally - oriented solutions. Think about an microprocessor board, which has 5 type of io communications port. Lets say these are RS232, USB1, USB2, LPT, and Bluetooth. Now do you represent those as a collection of 5 sets of methods? or as 5 stateful io_port objects? 5 io_port objects, right? But in your constructor, you would have to call another method elsewhere to query which ports existed in the middle of runtime. With a class attribute, you wouldn't. The appropriate resource method would be called once only (when the library was first loaded into memory and the port object instantiated). Thats a 'too clean' and over-simplified example. Things actually are much more tricky than that in real libraries. The paradigm also holds true for many different types of resource used by a library. Just look at Apple's cocoa frameworks. IOKit, AppKit and such. They don't have class as object so instead they use something called a singleton class in their library runtimes. Its essentially the same thing. dreamcat4 dreamcat4@gmail.com -- Posted via http://www.ruby-forum.com/.