From: Robert Klemme <shortcutter@...>
Date: 2009-10-14T04:01:46+09:00
Subject: Re: Class Level inheritable attributes - are we there yet?

On 13.10.2009 20:07, Dreamcat Four wrote:
> Robert Klemme wrote:
>> My understanding of the above is this.  You have two use cases in mind:
>>
>> 1. Inheriting dynamic attribute values defining a proximity rule, i.e.
>> when asked you get the closest attribute.
> 
> Yes. I have been using this way for the YamlDoc Gem
> 
>> 2. Constants which with the same proximity lookup rule as above only
>> that values do not change after the initialization.
> 
> No. I dont suggest that.

Well, it _is_ in the language already.

>> Before promoting something to the standard library I would also like
>> to know how much use cases there are.  In other words if (unlikely
>> worst case) you and Ara would be the only once that have a need for
>> this then I'd vote for not including in the std lib.
>>
>> Right now I have two issues:
>>
>> 1. I still have not seen a use case which would cry for a library
>> solution which is not there yet (see above).  (I still need to ponder
>> the board example in your other email.)
> 
> Its more that people generally know about @@ and expect it to be 
> correctly implemented.

I had hoped for a more concrete use case...

>> 2. It seems there are not many people wanting this (yet) - which might
>> well be caused by the fact that I don't read every single posting to
>> ruby-talk.  I do have a feeling though that if there was massive
>> demand for this we would see it in the std lib by now.
> 
> It honestly doesn't bother me that its not in Ruby StdLib because we all 
> know that @@ is completely broken. And when new people learn the ruby 
> language they are typically faced at some point with a blog post saying 
> 'dont use @@' because... Most people just gloss over that to go on and 
> learn about blocks, modules, and such constructs in Ruby.
> 
> In regards to demand for a clia_attr and to be a stand-in for @@...
> 
> Its comparatively harder for people to understand and use effectively 
> until they can have something better in their hand. So if others can 
> think up better declaration / semantics, syntax, well thats allright 
> then.

Well, there is a better tool: class instance variables.  Most if not all 
threads I have seen that contain class variables at some point end with 
the suggestion to use class instance variables.  This tells me that 
there is a better tool and inheritance of those is not needed.  I may be 
wrong though which is why I would love to see proper use cases that 
demand a new feature that is not yet present in the language or std lib.

We seem to talk a bit past each other and I get the impression that it 
is in part because you leave many of the points I raised unanswered.

Regards

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/