# Making Instace Variables Private/Local

**URL:** <https://rubytalk.org/t/making-instace-variables-private-local/2721>\
**Category:** ruby-talk\
**Created:** [7 November 2002 14:28 UTC](https://rubytalk.org/t/making-instace-variables-private-local/2721 "2002-11-07T14:28:29Z")\
**Posts on this page:** 7\
**Page:** 2

<div class="post-metadata">

**Author:** ![Gavin\_Sinclair](https://avatars.discourse-cdn.com/v4/letter/g/db5fbb/32.png) [@Gavin\_Sinclair](https://rubytalk.org/u/Gavin_Sinclair)\
**Post date:** [10 November 2002 13:45 UTC](https://rubytalk.org/t/making-instace-variables-private-local/2721/21 "2002-11-10T13:45:29Z")

</div>

> > If C++ and Java allow derived classes to access parent’s instance  
> > variables,  
> > then why not Ruby? Granted, at least in these languages, instance  
> > variables  
> > can be made genuinely private, but I don’t think it would make sense for  
> > Ruby  
> > to make _all_ instance variables private.
> 
> Hi Gavin,
> 
> But remember, C++ and Java are _statically typed_ languages. I can just  
> check the one and only one place of variable declarations and I know all  
> the instance variables. Not so with Ruby; it is fundamentally difficult  
> to know whether I accidentaly overwrite someone else’s variable with the  
> same name; only bugs will reveal that… 🙂
> 
> Bill

Good point. For this general reason, I usually endeavour to enumerate my  
instance variables somewhere near the top of the class definition. Nothing  
hard and fast - just something to remind me what I’m using, even if it’s just  
initialising then in the constructor.

Gavin

> **···**
>
> From: “William Djaja Tjokroaminata” [billtj@z.glue.umd.edu](mailto:billtj@z.glue.umd.edu)
> 
> > Gavin Sinclair [gsinclair@soyabean.com.au](mailto:gsinclair@soyabean.com.au) wrote:

---

<div class="post-metadata">

**Author:** ![Yohanes\_Santoso3](https://avatars.discourse-cdn.com/v4/letter/y/41988e/32.png) [@Yohanes\_Santoso3](https://rubytalk.org/u/Yohanes_Santoso3)\
**Post date:** [8 November 2002 16:54 UTC](https://rubytalk.org/t/making-instace-variables-private-local/2721/22 "2002-11-08T16:54:11Z")

</div>

William Djaja Tjokroaminata [billtj@z.glue.umd.edu](mailto:billtj@z.glue.umd.edu) writes:

> If I am the project manager, I will enforce this to my subordinates: when  
> the class local variables are available, then everyone will use only class  
> local (private) variables, and child classes will access the parent’s data  
> using methods, never the variables directly. In this way there is no risk

Well, you could try the untested code below to privatise parent’s  
instance variables. You’ll need Wayne Conrad’s stack frame patch:  
[http://yagni.com/stack\_frames/index.php](http://yagni.com/stack_frames/index.php)

class Module  
def attr\_local(\*args)  
args.each {|arg|  
if not arg.is\_a? Symbol  
raise “attr\_local is supplied with non-symbol arguments”  
end  
get\_block = %q{def #{arg.to\_s}  
if stack\_frames[0].class.is\_a? self  
raise “unauthorised access to local variable”  
else  
@#{arg.to\_s}  
end}  
set\_block = %q{def #{arg.to\_s}=(value)  
if stack\_frames[0].class.is\_a? self  
raise “unauthorised access to local variable”  
else  
@#{arg.to\_s} = value  
end}  
module\_eval get\_block  
module\_eval set\_block  
}  
end  
end

But, really, humans (programmers) must bear some responsibility. The  
situation is like the interface. You can define interfaces, but those  
who implement them are not guaranteed to give the functionality you  
expect.

Like (java):

interface Consume {  
public void eat();  
}

class Human implements Consume { … };  
class IOStream implements Consume { … };

Both classes implement two methods with the same name, but totally  
different behaviours. So, in the end it’s still the programmers’  
responsibility to make things sensible.

YS.

---

<div class="post-metadata">

**Author:** ![Paul\_Brannan](https://avatars.discourse-cdn.com/v4/letter/p/76d3ee/32.png) [@Paul\_Brannan](https://rubytalk.org/u/Paul_Brannan)\
**Post date:** [9 November 2002 07:25 UTC](https://rubytalk.org/t/making-instace-variables-private-local/2721/23 "2002-11-09T07:25:48Z")

</div>

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

> **···**
>
> 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.

---

<div class="post-metadata">

**Author:** ![William\_Djaja\_Tjokr1](https://avatars.discourse-cdn.com/v4/letter/w/87869e/32.png) [@William\_Djaja\_Tjokr1](https://rubytalk.org/u/William_Djaja_Tjokr1)\
**Post date:** [11 November 2002 17:46 UTC](https://rubytalk.org/t/making-instace-variables-private-local/2721/24 "2002-11-11T17:46:20Z")

</div>

Hi Yohanes,

> Well, you could try the untested code below to privatise parent’s  
> instance variables. You’ll need Wayne Conrad’s stack frame patch:  
> [http://yagni.com/stack\_frames/index.php](http://yagni.com/stack_frames/index.php)

Thanks for the code.

> But, really, humans (programmers) must bear some responsibility. The  
> situation is like the interface. You can define interfaces, but those  
> who implement them are not guaranteed to give the functionality you  
> expect.

> Like (java):

> interface Consume {  
> public void eat();  
> }

> class Human implements Consume { … };  
> class IOStream implements Consume { … };

> Both classes implement two methods with the same name, but totally  
> different behaviours. So, in the end it’s still the programmers’  
> responsibility to make things sensible.

I totally agree with you. I just want the language itself to provide more  
protection for the human programmer, especially for the  
“innocent/accidental” mistakes. Just like C++, we have Meyers’ “Effective  
C++ Ways”, but we still can get pointer errors; on the other hand, in Java  
there is no way we will get pointer error (in the C sense). Similarly in  
Ruby, if all instance variables are class local/private, then I have one  
fewer thing to worry about in a multi-people projects.

Regards,

Bill

> **···**
>
> Yohanes Santoso [ysantoso@jenny-gnome.dyndns.org](mailto:ysantoso@jenny-gnome.dyndns.org) wrote:

---

<div class="post-metadata">

**Author:** ![William\_Djaja\_Tjokr1](https://avatars.discourse-cdn.com/v4/letter/w/87869e/32.png) [@William\_Djaja\_Tjokr1](https://rubytalk.org/u/William_Djaja_Tjokr1)\
**Post date:** [11 November 2002 18:06 UTC](https://rubytalk.org/t/making-instace-variables-private-local/2721/25 "2002-11-11T18:06:25Z")

</div>

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

> **···**
>
> Paul Brannan [pbrannan@atdesk.com](mailto: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

---

<div class="post-metadata">

**Author:** ![Bulat\_Ziganshin](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Bulat\_Ziganshin](https://rubytalk.org/u/Bulat_Ziganshin)\
**Post date:** [12 November 2002 05:54 UTC](https://rubytalk.org/t/making-instace-variables-private-local/2721/26 "2002-11-12T05:54:29Z")

</div>

Hello William,

Monday, November 11, 2002, 9:06:25 PM, you wrote:

> (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?)

```
     - Ruby can't be compiled: it's too easy and toy langugae for
     Real Programmers (R). You had better to use C and asm
     instead, preferably asm"

     :)

```

> **···**
>
> –  
> Best regards,  
> Bulat [mailto:bulatz@integ.ru](mailto:bulatz@integ.ru)

---

<div class="post-metadata">

**Author:** ![David\_Alan\_Black1](https://avatars.discourse-cdn.com/v4/letter/d/278dde/32.png) [@David\_Alan\_Black1](https://rubytalk.org/u/David_Alan_Black1)\
**Post date:** [13 November 2002 15:50 UTC](https://rubytalk.org/t/making-instace-variables-private-local/2721/27 "2002-11-13T15:50:04Z")

</div>

Hi –

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

I happen to like power, flexibility, and fun… but in any case, I’d  
be very careful in doing this kind of reshaping of the interpreter,  
since libraries you include may well do the things you’d be hacking  
out of the language. It might be better to achieve robustness and  
safety by having coding standards for your group. (I’m completely  
inexperienced in big projects, so I’m just speculating.)

David

> **···**
>
> On Tue, 12 Nov 2002, William Djaja Tjokroaminata wrote:
> 
> –  
> David Alan Black  
> home: [dblack@candle.superlink.net](mailto:dblack@candle.superlink.net)  
> work: blackdav@shu.edu  
> Web: [http://pirate.shu.edu/~blackdav](http://pirate.shu.edu/~blackdav)

[Previous page](https://rubytalk.org/t/making-instace-variables-private-local/2721.md?page=1)