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

On Dec 5, 2003, at 15:10, Weirich, James wrote:

>> 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.
>
> My understanding is that we were worried about /accidental/ shadowing. 
>  If
> it is accidental, we don't know about the variable in the superclass,
> therefore won't need to access it.

Perhaps it's a bit over-contrived, but what about when you start out 
not caring, and then decide you do care? So you sub-class A, add lots 
of functionality to your subclass, and then realize that you need 
access to an instance variable of A's that you've shadowed?


One aspect of my distaste for class local instance variables (and 
class-local methods, too) really has to do with the fact that they 
prevent an instance from accessing data (or behavior) that is a 
fundamental part of that instance's make-up. When an object is 
instantiated, a separate instance isn't created for each Class (and 
Module) in its inheritance chain - rather, one instance is created that 
represents a composite of the whole inheritance chain. Class local 
instance variables take an instance that was a cohesive whole and turn 
it in to a bunch of little pieces. This is perhaps OK, but I think the 
lines drawn within an instance need to be drawn in light pencil, not 
with indelible marker.

The other aspect that bothers me is that I don't like library writers 
being too 'smart' about what I do and don't want to be able to do with 
their library. Instance variable shadowing is a problem, but the cure 
is worse than the disease if it introduces a construct that prevents me 
from doing hokey things with the internals of a super-class IF I WANT 
TO. I don't think re-opening classes is a valid means of working around 
this, because if I re-open a class to do hokey things with its 
internals, I affect not just my subclass of that class, but every 
subclass of that class in the system.


> Accessor shadowing is a bit more worrysome because it overrides 
> accessor
> calls in the superclass as well.

But can you separate instance variables from accessors? Ruby currently 
encourages a very minimal distinction between the two (a minimalism 
that I think is great), but if variables and methods are treated 
differently when inherited, that distinction becomes much more 
important (or troublesome, depending on how you look at it).


To all those involved, these are mostly the ramblings of a concerned 
mind... I don't necessarily have a better idea, I just fear a worse one 
gaining strength. I don't just think @_ is ugly, I think the underlying 
solution is wrong altogether, and I'm hoping for a better one. But in 
the end, I think a (paraphrased) Hal quote fits here: "I don't know why 
I always get worried when people propose language changes I don't 
like... Matz does a pretty good job keeping Ruby, Ruby."


Nathaniel

<:((><