From: Nathaniel Talbott <nathaniel@...>
Date: 2003-12-06T05:05:57+09:00
Subject: Re: Attempted roadmap of future instance variables....

On Dec 5, 2003, at 14:47, T. Onoma wrote:

> On Friday 05 December 2003 07:40 pm, Nathaniel Talbott wrote:
>> The core of the problem that class local instance variables are trying
>> to solve is variable shadowing (as Guy so elegantly showed). The
>> problem with making all variables class local and using accessors, is
>> that if I am shadowing an instance variable, there is a good chance
>> that I will shadow the accessor as well. The superclass variable thus
>> becomes completely inaccessible:
>
> I see what you're saying, but I would think you would know that you 
> were doing
> this if you were subclassing, just as you know it when you want to 
> redefine a
> method of the superclass.

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


>>    # pretend all instance variables are class local
>>    class A
>>      attr_accessor :a
>>
>>      def initialize
>>        @a = 1
>>      end
>>    end
>>
>>    class B < A
>>      attr_accessor :a
>>
>>      def initialize
>>        @a = 'a'
>>      end
>>    end
>>
>> There is no way for the subclass to access the superclass's instance
>> variable @a now, and I don't see a good work-around for this.
>
> So it would seem to me, that in fact, this is an example of one 
> actually
> wanting to redefine the accessor to cut the scope off at the subclass, 
> so
> that @a of the superclass could no longer be accessed. A purposeful 
> act.

Er, no. Not purposeful at all. I just required class A from who knows 
what library, and just want to subclass it and get going. I have no 
earthly idea that it uses the @a instance variable, and @a is a great 
variable name for the code I'm writing, so I use it, not realizing that 
I'm shadowing A's @a. Then, later, I realize that I need to access @a 
in A, and that I have to rename my variable to do so (weren't we doing 
this to prevent having to rename due to name clashes?). Or, worse, A 
depends on self.a referring to its version of @a, and thus is broken by 
my re-defining of attr_accessor :a.

Ick.


>> I wonder if a better solution for the issue doesn't lie in the idea of
>> namespaces. Basically, library writers want to be able to say that
>> @checkpoint is part of the Transaction::Simple namespace, and
>> occasionally library users want to say that they want to read or write
>> @checkpoint in the Transaction::Simple namespace. If there was a way 
>> to
>> explicitly limit the namespace of an instance variable to a given 
>> Class
>> or Module, and a way to access an instance variable in an explicit
>> Class or Module, that would be quite handy. The key is that all data
>> remains accessible all the time, to everyone. We just allow folks the
>> ability to shadow.
>
> You can always just augment the superclass/module to give you the 
> access you
> need:
>
>   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.


Nathaniel

<:((><