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
Gavin Sinclair gsinclair@soyabean.com.au wrote:
William Djaja Tjokroaminata 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
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.
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.
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
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 wrote:
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 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
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
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
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav