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
[e-mail]
-- 
Posted via http://www.ruby-forum.com/.