From: "T. Onoma" <transami@...>
Date: 2003-12-06T05:44:44+09:00
Subject: Re: Attempted roadmap of future instance variables....

On Friday 05 December 2003 09:05 pm, Nathaniel Talbott wrote:
> Then why mess with class local instance variables at all? If I already
> know that I'm shadowing, then obviously I would pick a different name
> and NOT shadow. I think the issue is when one is using a library and
> doesn't know what instance variables it uses internally. I agree, it's
> a shaky premise that one would not know this (or figure it out real
> fast), and thus I tend to think the premise that Ruby needs class local
> variables is rather shaky itself. The only real reason for it is when a
> library writer wants to be able to use a common variable name (like
> @message or something) and doesn't want to cause those using his
> library name clashes (and doesn't want to use ugly names like
> @__message__.

The concept of local instance variable actually does make a lot of sense when 
you think about it in a more tangebale way. The idea can be most clearly 
understood, I think, by way of analogy: Local instance varibales are to class 
instances as local variables are to methods. If you consider this poignant 
analogy carefully I think you will see why they are desirable.

> >
> >   module Transaction::Simple
> >      def simple_checkpoint
> >         @checkpoint
> >      end
> >   end
>
> Maybe it's just me, but I do NOT want to have to re-open a third-party
> library to be able to access data that should be (and is, in current
> Ruby) already accessible to me.

Instance varaibles really aren't intended to be open like this. It prevents 
the library builder from clearly defining the interface by which one is to 
generally use the library. For a particular case, as you suggest, in which 
one does in fact need access to an instance variable that is not provided 
through an accessor method, it is likely that the library maintainer would 
want to know about it, so they could incorporate that access. One can of 
course just take issue with the immediate restraint this causes, but in the 
end it actually improves code and its reusability.

T.