From: "David A. Black" <dblack@...>
Date: 2003-12-07T21:36:41+09:00
Subject: Re: Attempted roadmap of future instance variables....

Hi --

On Sun, 7 Dec 2003, Jesse Tov wrote:

> After a lot of discussion about this, it seems clear to me that the point
> of instance local variables isn't about privacy so much as preventing
> accidental collisions.  That calls for a solution that makes it easy
> to access parents' instance locals, while still differentiating their
> namespaces.  The proposed use of "namespace" seems a bit syntactically
> heavy, though.  So, I'm going to propose something analogous to the
> case of Foo versus ::Foo:
> 
>      @a         instance local
>      @::a       parent's instance local
>      @Foo::a    ancestor-named-Foo's instance local
> 
> It doesn't add anything new, since :: already exists for similar things.
> It's lightweight and non-restrictive, and seems to blend into the
> language pretty well to me.

You're right that :: already exists in the language, but I think
there's a big difference between using, say, A::x or A::X to get at a
class method or constant, and using @A::x to get at an instance
variable that happens to have been used in methods defined in A --
namely, that A::x and A::X are documented.  Whoever's writing the
class definition of A is not going to treat @x (and shouldn't have to
treat it) like part of the public interface, for purposes of
documentation, version-number adjustment for incompatible releases,
etc. 

Here's an example of breakage under innocent refactoring:

  class A
    def learn; @speech ||= "Hello"; end
    def talk; puts @speech; end
  end

  class B < A
  end

  class C < B
    def yell; puts @A::speech.uppercase
  end

Then we (or some library writer) decides to do this instead:

  class Speaker; def learn... def talk... end
  class A < Speaker; end

etc.

So now the variable is @Speaker::speech, so the definition of yell
doesn't work.  

One could say: the solution is to study the code you're inheriting
from.  In that case, though, name collision isn't going to be an
issue.  But that, too, really unencapsulates things.  


David

-- 
David A. Black
dblack@wobblini.net