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

David A. Black <[e-mail]>:
> On Sat, 6 Dec 2003, Yukihiro Matsumoto wrote:
>> I don't think so.  Python has basically same feature.  attributes with
>> preceding "__" becomes class local in Python.
> 
> It could still be an argument against Ruby in the sense that it might
> take away part of one argument *for* Ruby, in some people's minds, in
> a situation like that.

[If you don't want to read my rambling about language design and some
rationale, please skip down to my proposal at "TALKING ABOUT RUBY
STARTS HERE."]

"__" is one of the things that turned me off to Python.  It wasn't
explained in the tutorials I read, so it was confusing.  Magic names
seem to be in general confusing to newbies.  Two examples:

  1. I decided to learn Dylan last week, and I spent quite a while
     wondering if there was some signficance to *variable-names-like-this*
     or to <Classes-like-this>.  It was a while before I found out
     that it's just convention.

  2. A friend of mine spent all night a few weeks ago trying to get
     a Haskell program to compile.  He didn't know that type
     constructors and data constructors have to start with a capital
     letter (well, or a colon).

These lexical rules can be confusing, and Perl-style punctuation
on names is ugly, but we have good reasons for them.  For example,
Haskell's rules remove some funny ambiguities that show up with SML
pattern matching.  (fun X = 5 -- is X a variable or a nullary data
constructor?  It depends...)  Likewise, Perl's @&$% names make
"auto-vivication" work better, if auto-vivication could ever be said
to work well.

However, languages aren't designed for newbies.  Introductory tutorials
should make issues like naming clear, and languages should be designed to
work best for the people actually writing lots of code in them.

TALKING ABOUT RUBY STARTS HERE

I should write about Ruby, in case anyone's still reading, since I have
a proposal.  Ruby's naming rules exist for a really good reason:  To
make it easy to use differently-scoped variables without ever declaring
anything about them.  (Unless Matz says differently, I guess.)  Adding a
new kind of variable that requires a declaration, as some have suggested,
would be pretty inconsistent.  Adding a new prefix (@_a) would be
consistent, but it adds to the confusion.  On the other hand, it would
be easy to search for where it breaks old code.

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.  Here's an example:

    class A
      def a=(x)
        @foo = x
      end
    end

    class B < A
      def b=(x)
        @foo = x
      end
    end

    class C < B
      def c=(x)
        @foo = x
      end

      def c;
        @foo
      end

      def b;
        @::foo    # could also be @B::foo
      end

      def a
        @A::foo
      end
    end

    c = C.new
    c.a = 1
    c.b = 2
    c.c = 3

    puts(c.a, c.b, c.c)   ==> 1, 2, 3

Jesse

(Please forgive me for delurking in this fashion.)