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

On Friday 05 December 2003 11:24 pm, Nathaniel Talbott wrote:
> 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 ;-)

I suppose I should have spelled it out, so that you would see the actual 
analogy rather that contrive it to fit your argument. These "scopes enclosed 
in a method" are not analogous as they have no inheritability, as do classes 
and their methods. Local variables prevent name clashing between methods, 
even when they are "inherited":

  class A
    def x
      a = "A"
    end
  end

  class B < A
    def x
      a = "B"
      super
      a
    end
  end

  b = B.new
  b.x   # => "B"

Just as class B has inherited the superclass A, so too has the method B#x 
inherited the functionaity of A#x by using super. Yet their local namespace 
remains distinct. The result of b.x is not "A", but rather "B".  While it is 
quite possible to program without local variables altogther, it is much more 
advantages to use them for the seperation of scope they provide. The same is 
true for class local instance variables.

So you see, I have certainly NOT made your argument for you, but to the 
contrary. You did not consider the analogy carefully. [ Not that I'm one to 
talk, mind you ;-) ]

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

Okay, first of all, the whole "ugly hack" thing about "re-opening a library 
class" has gots to go. That idea is simply way off base. This is NOT an ugly 
hack. It is done regularly and with good reason. I for instance almost always 
"re-open" NilClass to add a few extra methods. This is extremely clean, and 
as long as I have done so with careful consideration to the context I am 
applying it, works beautifully, and is why we have the functionality in the 
first place. An "ugly hack" would be me trying to subclass NilClass and 
telling every other class that I require to use MyNilClass it its place.

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

Argue? You suggest, and if the maintainer says "no", then they have their 
reasons. If they don't exist, then why care what you do to their (who's?) 
library. And no one's forcing anyone. That you might discover a local 
instance variable that could be useful to the "outside" is simply something a 
library maintatiner would normally want to know about. Furthermore it means 
you must really know that library pretty dang well, so clashing method names 
is about the most unlikely occurance you would ever face. In fact, it just 
doesn't happen. No one uses a library class wearing a blind fold.

T.