If you are still considering to use ‘@_var’ or ‘@__var’ to create class
private/local variables, are you open to the idea of simply making all
instance variables private? The descendant classes then can access the
instance variables using ‘self.var’, where the method ‘var’ can either be
public or protected.
The reason I ask is because it seems that you are considering things like
‘abc[0]’ which will return the “char” instead of the “fixnum” in 1.9,
which may break a lot of codes. So although currently making all instance
variables private will also break a lot of codes, probably the
“transition” can be handled in the same way as the behavior change of
‘abc[0]’. But first of course I want to know whether you think making all
instance variables private is a good idea in the first place (ignoring
the backward compatibility issue for now), especially from the
object-oriented data hiding point of view, and in particular for doing
large-scale software development.
It’s probably not intuitive to anybody (except perhaps Matz). However,
I see
no particular justification for it being any other way, and in fact it’s
changing in 1.7 isn’t it? Anyway, my point is: you’ll never forget it
now.
And if you’re like me, you won’t care either.
If you are still considering to use ‘@_var’ or ‘@__var’ to create class
private/local variables, are you open to the idea of simply making all
instance variables private? The descendant classes then can access the
instance variables using ‘self.var’, where the method ‘var’ can either be
public or protected.
Your second sentence doesn’t necessarily relate to your initial
question Meaning: whether instance vars are private or not,
there’s no reason to think that every instance var is going to have
one of these:
def var @var
end
associated with it. All sorts of other permutations are
possible… including no accessor method, or this:
def var @thing
end
or this:
def var @var * 2
end
etc.
David
···
On Thu, 7 Nov 2002, William Djaja Tjokroaminata wrote:
In message “Making Instace Variables Private/Local” on 02/11/07, William Djaja Tjokroaminata billtj@y.glue.umd.edu writes:
If you are still considering to use ‘@_var’ or ‘@__var’ to create class
private/local variables, are you open to the idea of simply making all
instance variables private? The descendant classes then can access the
instance variables using ‘self.var’, where the method ‘var’ can either be
public or protected.
I am not brave enough to introduce such incompatibility. I guess more
than 60% of Ruby programs will not run after such change.
Meaning: whether instance vars are private or not,
Well, the problem is that the use of "private instance variable" is very
bad when someone want to refer to @__var, class local variable seems
better (see [ruby-talk:50212] and [ruby-talk:50242])
I think Bill’s point is that it would be better for instance variables
to be hidden behind an interface made up of public or protected methods
so that the implementation of a base class can change without breaking
derived classes. And I have to agree with him.
On Thu, 7 Nov 2002, William Djaja Tjokroaminata wrote:
If you are still considering to use ‘@_var’ or ‘@__var’ to create class
private/local variables, are you open to the idea of simply making all
instance variables private? The descendant classes then can access the
instance variables using ‘self.var’, where the method ‘var’ can either be
public or protected.
Your second sentence doesn’t necessarily relate to your initial
question Meaning: whether instance vars are private or not,
there’s no reason to think that every instance var is going to have
one of these:
def var @var
end
associated with it. All sorts of other permutations are
possible… including no accessor method, or this:
Your second sentence doesn’t necessarily relate to your initial
question Meaning: whether instance vars are private or not,
there’s no reason to think that every instance var is going to have
one of these:
def var @var
end
associated with it. All sorts of other permutations are
possible… including no accessor method.
Hi David,
Totally agree. However, the intent of making all instance variables
private is that when a child class writes ‘@var’, it is a variable that
belongs to that specific child class so that a child class will never
accidentally overwrites a variable belonging to its parent. A child is
never supposed to know its parent’s business; a child is given access only
through its parent’s methods (which may or may not represent a
simple/direct access to the parent’s instance variables with similar
names).
In the case that a child really needs access to its parent’s ‘@var’ but
the parent does not provide any method to access it, then the parent class
definition can be reopened to provide ‘def var; @var; end’. So a child
always accesses its parent’s data using ‘self.var’ (or other
‘self.something’) but never ‘@var’.
I guess if you really introduce class local variables (@__var) then
probably people can start migrating to using class local variables and
child classes can start accessing parent’s data using methods. But of
course this boils down to your opinion, whether those 60% of Ruby programs
are better off by migrating to internal data/interface separation. (In
other words, whether you decide that it is perfectly fine that a child
class accesses its parent class data directly in terms of ‘@var’ and not
‘self.var’.)
(For me personally, rather than having the not-very-nice-looking @__var
forever, it is probably better to have some transition period, just like
things that are “deprecated”, such as “type”.)
I am also wondering, among those people who wrote the 60% of Ruby
programs, did it ever occur to any of them in the past an idea to provide
data encapsulation/hiding/protection by accessing parent data using an
interface (accessor method) instead of accessing the parent data directly?
In message “Making Instace Variables Private/Local” > on 02/11/07, William Djaja Tjokroaminata billtj@y.glue.umd.edu writes:
If you are still considering to use ‘@_var’ or ‘@__var’ to create class
private/local variables, are you open to the idea of simply making all
instance variables private? The descendant classes then can access the
instance variables using ‘self.var’, where the method ‘var’ can either be
public or protected.
I am not brave enough to introduce such incompatibility. I guess more
than 60% of Ruby programs will not run after such change.
Put another way: do you think it is The Right Thing?
IMHO it is closer to it than what we have now.
PS: first post!
···
On Fri, Nov 08, 2002 at 03:14:36AM +0900, Yukihiro Matsumoto wrote:
Hi,
In message “Making Instace Variables Private/Local” > on 02/11/07, William Djaja Tjokroaminata billtj@y.glue.umd.edu writes:
If you are still considering to use ‘@_var’ or ‘@__var’ to create class
private/local variables, are you open to the idea of simply making all
instance variables private? The descendant classes then can access the
instance variables using ‘self.var’, where the method ‘var’ can either be
public or protected.
I am not brave enough to introduce such incompatibility. I guess more
than 60% of Ruby programs will not run after such change.
I really think that, except the backward compatibility issue, making all
instance variables “class local variables” will make Ruby even more
suitable for large scale software development and not just
“scripting”. (And “big” software is good, because it is where
corporations usually pour most of their money into )
Does anyone see any disadvantages of doing this, other than:
Backward compatibility issue (which IMO should be handled in the same
way as the String#[fixnum] behavior change)
Performance (which can be handled cleanly by changing the class local
variables to C struct’s if performance is really important)
I think Bill’s point is that it would be better for instance variables
to be hidden behind an interface made up of public or protected methods
so that the implementation of a base class can change without breaking
derived classes. And I have to agree with him.
Bill, you seem to wait about a week between each restart of this topic. Do
you really think that things will change in that short time? I think that to
champion this topic is positive indication that the concept of inheritance in
OOD is still not grasped.
···
–
“Every real thought on every real subject knocks the
wind out of somebody or other.”
-Oliver Wendell Holmes, Sr.
(In
other words, whether you decide that it is perfectly fine that a child
class accesses its parent class data directly in terms of ‘@var’ and not
‘self.var’.)
Bill
The only other OO (rather, OI - Object Influenced) languages I know are C++ and
Java. In both of these, derived classes have access to parent classes’ public
(obviously) and protected instance variables.
It seems that the Ruby model is that all instance variables are a mix:
protected, because children can access them; and
private, because other objects of the same class can’t access them
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.
In my (limited) experience, there is less need for inheritance in Ruby than in
C++/Java, because dynamic binding takes place all the time, and because classes
can be modified. This is great, because in Ruby you only inherit when it
genuinely makes sense, rather than as a convenience for modifying behaviour. A
corollary of this is that you should be able to manage your inheritence trees
sufficiently to avoid trampling on parent’s data. Just my 2c.
Let’s see: Dave Thomas gave a presentation on a 26kloc production
business system he wrote over the summer in Ruby. I have a project
with about 10kloc’s of Ruby controlling a distributed agent society
of 40+ machines in a highly dynamic environment…being used every
day. I never had a need with what you are asking for, and obviously
Dave didn’t.
I think the main barrier to writing production systems in Ruby is
people talking about why it cannot be done and not spending the
time doing it.
-Rich
···
-----Original Message-----
From: Gavin Sinclair [mailto:gsinclair@soyabean.com.au]
Sent: Thursday, November 07, 2002 6:30 PM
To: ruby-talk ML
Subject: Re: Making Instace Variables Private/Local
(In
other words, whether you decide that it is perfectly fine
that a child
class accesses its parent class data directly in terms of
‘@var’ and
not
‘self.var’.)
Bill
The only other OO (rather, OI - Object Influenced) languages
I know are C++ and Java. In both of these, derived classes
have access to parent classes’ public
(obviously) and protected instance variables.
It seems that the Ruby model is that all instance variables are a mix:
protected, because children can access them; and
private, because other objects of the same class can’t
access them
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.
In my (limited) experience, there is less need for
inheritance in Ruby than in
C++/Java, because dynamic binding takes place all the time,
and because
C++classes
can be modified. This is great, because in Ruby you only
inherit when it genuinely makes sense, rather than as a
convenience for modifying behaviour. A corollary of this is
that you should be able to manage your inheritence trees
sufficiently to avoid trampling on parent’s data. Just my 2c.
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…
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.
Well, it is not about not spending the time doing it; I want to do it, but
to do it in the right way. Really, for a one-person project, if he/she
overwrite his/her own variable of the same name, it is his/her own
problem. But in multi-person project, with a stratagey of, for example,
one person is responsible for one class in a inheritance tree, the
“protected” instance variables can only cause bugs. (This problem IMO is
the very reason Matz was considering the creation of class local
variables.)
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
of bugs because someone by accident creates an identical variable
name. Also, we can change the implementation of a parent class by
changing the instance variables (but not the methods) without breaking any
child classes.
However, if a rule is only a rule specified by people, and not enforced by
the language itself, then it is not good. People can still abuse it
(either intentionally or accidentally). An example is of course C++.
I really want to sell Ruby to the corporate world, but I do not like to
follow the Perl path, but instead I prefer the Java path. I want Matz’s
picture to be on the cover of Time magazine and not just Linux Journal
magazine (such as Larry Wall).
Let’s see: Dave Thomas gave a presentation on a 26kloc production
business system he wrote over the summer in Ruby. I have a project
with about 10kloc’s of Ruby controlling a distributed agent society
of 40+ machines in a highly dynamic environment…being used every
day. I never had a need with what you are asking for, and obviously
Dave didn’t.
I think the main barrier to writing production systems in Ruby is
people talking about why it cannot be done and not spending the
time doing it.
In message “Re: Making Instace Variables Private/Local” on 02/11/09, William Djaja Tjokroaminata billtj@z.glue.umd.edu writes:
Do you have any technical reason for this? (I am trying to learn OO from
you.) Or is it just a dogma or style?
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.
Meaning: whether instance vars are private or not,