Making Instace Variables Private/Local 
Author Message
 Making Instace Variables Private/Local

Hi Matz,


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.

Regards,

Bill
============================================================================
Hi,

In message "Re: Thoughts on Ruby"

(regarding the fact "abc"[0] being fixnum)

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

It will in 1.9 or later.

                                                        matz.



Mon, 25 Apr 2005 22:23:46 GMT  
 Making Instace Variables Private/Local
Hi --

Quote:


> 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

  end

associated with it.  All sorts of other permutations are
possible... including no accessor method, or this:

  def var

  end

or this:

  def var

  end

etc.

David

--
David Alan Black


Web:  http://pirate.shu.edu/~blackdav



Mon, 25 Apr 2005 23:31:37 GMT  
 Making Instace Variables Private/Local

d> Meaning: whether instance vars are private or not,

 Well, the problem is that the use of "private instance variable" is very

 better (see [ruby-talk:50212] and [ruby-talk:50242])

Guy Decoux



Mon, 25 Apr 2005 23:42:59 GMT  
 Making Instace Variables Private/Local
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.

Cheers,
        Nat.

Quote:

> Hi --



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

>   end

> associated with it.  All sorts of other permutations are
> possible... including no accessor method, or this:

>   def var

>   end

> or this:

>   def var

>   end

> etc.

> David

> --
> David Alan Black


> Web:  http://pirate.shu.edu/~blackdav

--
Dr. Nathaniel Pryce, Technical Director, B13media Ltd.
Studio 3a, 22-24 Highbury Grove, London N5 2EA, UK
http://www.b13media.com


Mon, 25 Apr 2005 23:50:19 GMT  
 Making Instace Variables Private/Local

Quote:

> 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

>   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

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


the parent does not provide any method to access it, then the parent class

always accesses its parent's data using 'self.var' (or other

Regards,

Bill



Mon, 25 Apr 2005 23:57:46 GMT  
 Making Instace Variables Private/Local

Quote:

> 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.
> Cheers,
>    Nat.

Hi Nat,

Thanks a lot for the support and clarification.

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:

1) Backward compatibility issue (which IMO should be handled in the same
way as the String#[fixnum] behavior change)

2) Performance (which can be handled cleanly by changing the class local
variables to C struct's if performance is really important)

Regards,

Bill



Tue, 26 Apr 2005 00:19:32 GMT  
 Making Instace Variables Private/Local
Hi,

In message "Making Instace Variables Private/Local"


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

                                                        matz.



Tue, 26 Apr 2005 02:14:36 GMT  
 Making Instace Variables Private/Local

Quote:

> Hi,
> In message "Making Instace Variables Private/Local"


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

Hi Matz,


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

'self.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?

Regards,

Bill



Tue, 26 Apr 2005 02:43:37 GMT  
 Making Instace Variables Private/Local

Quote:

> Hi,

> In message "Making Instace Variables Private/Local"


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

Were Ruby to be invented again, would you do it?

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!

from my new PC in my new dorm, I mean :-)
--
 _           _                            
| |__   __ _| |_ ___ _ __ ___   __ _ _ __  
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
        Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

On a normal ascii line, the only safe condition to detect is a 'BREAK'
- everything else having been assigned functions by Gnu EMACS.
        -- Tarl Neustaedter



Tue, 26 Apr 2005 02:52:27 GMT  
 Making Instace Variables Private/Local

Quote:

> Were Ruby to be invented again, would you do it?
> Put another way: do you think it is The Right Thing?

Hi batsman,

Thank you, thank you.  You can say it much better and more to the
point than I did.

Quote:
> PS: first post!
> from my new PC in my new dorm, I mean :-)
> --

Congratulations, batsman! :)

Regards,

Bill



Tue, 26 Apr 2005 05:09:03 GMT  
 Making Instace Variables Private/Local
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.


Tue, 26 Apr 2005 05:34:26 GMT  
 Making Instace Variables Private/Local
Hi,

In message "Re: Making Instace Variables Private/Local"

|Were Ruby to be invented again, would you do it?

Class local only?  No, I don't think so.

                                                        matz.



Tue, 26 Apr 2005 06:28:44 GMT  
 Making Instace Variables Private/Local

Quote:
> (In
> other words, whether you decide that it is perfectly fine that a child

> '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 {*filter*}ling on parent's data.  Just my 2c.

Gavin



Tue, 26 Apr 2005 07:30:23 GMT  
 Making Instace Variables Private/Local
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

Quote:
> -----Original Message-----

> 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

> > 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 {*filter*}ling on parent's data.  Just my 2c.

> Gavin



Tue, 26 Apr 2005 13:17:02 GMT  
 Making Instace Variables Private/Local

Quote:

> Hi,

> In message "Re: Making Instace Variables Private/Local"

> |Were Ruby to be invented again, would you do it?

> Class local only?  No, I don't think so.

This answer surprises me quite a lot, for the only tangible reason I can
think of is the speed issue. I really felt it was The Right Thing.

But if it's a matter of 'style', I'll just take it as it is, as I have
already stated I will trust you :-)

--
 _           _                            
| |__   __ _| |_ ___ _ __ ___   __ _ _ __  
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
        Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

"You, sir, are nothing but a pathetically lame salesdroid!
I fart in your general direction!"
        -- Randseed on #Linux



Tue, 26 Apr 2005 21:27:43 GMT  
 
 [ 27 post ]  Go to page: [1] [2]

 Relevant Pages 

1. local variable and local variable in block behave differently

2. Sequence local = local variable?

3. Local variables - lifetime and access variables [Q]

4. accessing a local variable in from a widgets -variable or -command properties

5. Making a class method private

6. NT setup making local copies of .tps files

7. Local boy makes good in a bad place

8. Dave Beazley (local boy makes good)

9. PRIVATE variables (was parameters)

10. Lots of Public and Private variables - no penalties on modern PC.

11. Public\private memory variables

12. Private variables can be changed outsid e?

 

 
Powered by phpBB® Forum Software