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.
Accessor shadowing is a bit more worrysome because it overrides accessor
calls in the superclass as well.
–
– Jim Weirich / Compuware
– FWP Capture Services
– Phone: 859-386-8855
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
<:((><
On Dec 5, 2003, at 15:10, Weirich, James wrote: