From: William Djaja Tjokroaminata <billtj@...>
Date: 2002-11-12T03:06:25+09:00
Subject: Re: Making Instace Variables Private/Local

Paul Brannan <pbrannan@atdesk.com> wrote:
> On Sat, Nov 09, 2002 at 11:55:33AM +0900, Yukihiro Matsumoto wrote:
>> Actually inheritance is a very heavy relationship between classes.
>> Once you've decided to inherit from other class, you have to know
>> inside of superclass anyway.

> I'm not sure I agree.

> In Ruby, this is true, because of how instance variables work.

> In C++, if I inherit, I need only know about my parent class's protected
> methods and data members; private methods/data members are an
> implementation detail that I need not worry about.  C++ and Ruby are
> very different languages, though, with very different requirements on
> the user.

> Paul

Hi,

I'm not sure that I agree with Matz either.  In C++ in general I make all
the data members private while methods can be public, protected, or
private.  In fact, one of the difficulties in inheriting from someone
else's class is if we have to know the inside details of the parent
class.  One level is usually the most that I could bear.  If the
inheritance is several levels deep and scattered around several files,
usually I just write my own class from scratch.  :)  For example, I can
inherit from the String class easily, because I don't need to know the
inner details of the String class (which is written in C); I just need to
know its methods.

When I am writing Ruby codes myself, it is indeed "fun" to be able to
access the parent instance variables directly (because I truly understand
all the details).  But now when I am considering multi-people projects, I
am more concerned about the "robustness" than the "fun factor".

(I have a feeling that I need to modify the Ruby interpreter to add some
switches such that:
    - all instance variables are class local/private
    - methods cannot be redifined (at least give some warning)
    - classes cannot be reopened
    - (others?)
All these are fine for a single-person project; in fact they add to the
"power", "flexibility", and "fun" of Ruby as a "scripting" language.  But
I feel I need to turn the switches on for "safety" reason in a 
large-scale, multi-people projects.)

Regards,

Bill