Re: Attempted roadmap of future instance variables....

On Dec 5, 2003, at 15:44, T. Onoma wrote:

> 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.

OK, lets work that out a bit more:

- When I use a local variable I'm saying, "Limit the scope to this 
method".
- When I use an instance variable I'm saying, "Limit the scope to this 
instance".

So if I apply your analogy (instance variables are to instances of 
classes as local variables are to methods), all instance variables 
should be accessible to all descendants of a given class, just as all 
local variables are available to all scopes enclosed in a method 
(except blocks, but that'll be fixed in 2.0.

I think you just made my argument for me ;-)


>>>
>>>   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.

Where did you read that? I wasn't aware that instance variables had a 
stated intent.


> 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.

"Prevents" seems like a pretty strong word. As a matter of fact, I 
don't think instance variables affect one iota a library writer's 
ability to clearly define the interface by which their library should 
generally be used. And yes, it is good to give feedback to library 
writers, but what if a library writer disagrees with my perceived need 
to access the internals of their library? Currently I can deal with 
that fairly cleanly by simply subclassing, and both I and the library 
writer are happy. With class local instance variables, either I have an 
ugly hack, or I pester the library writer until he adds an interface to 
his library that he really doesn't like. So... do class local instance 
variables PREVENT a library writer from defining an interface that he 
likes for his library? No, but he might end up having to support more 
special cases than he does under current Ruby.

Oh, and I don't see much point in digging in to the obvious problems 
that occur when you have a slow and/or nonexistent library maintainer, 
other than to say it's one more reason one shouldn't argue that a 
feature is good because, "it forces you to get the maintainer to 
incorporate what you need." Sort of like saying using proprietary 
software is good because, "You don't end up with a bunch of people 
fixing their own problems."

Just my $0.02,


Nathaniel

<:((><