Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!vuse.vanderbilt.edu!brian
From: brian@vuse.vanderbilt.edu (Brian Antao)
Newsgroups: comp.lang.smalltalk
Subject: Re: Access methods - New feature ?
Keywords: Access methods, Smalltalk-80
Message-ID: <1991Apr22.211145.11021@vuse.vanderbilt.edu>
Date: 22 Apr 91 21:11:45 GMT
References: <1991Apr21.221149.8057@vuse.vanderbilt.edu> <1991Apr22.003659.18658@ux1.cso.uiuc.edu>
Sender: news@vuse.vanderbilt.edu
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Lines: 47
Nntp-Posting-Host: ee6

In article <1991Apr22.003659.18658@ux1.cso.uiuc.edu> dawg6844@uxa.cso.uiuc.edu (Race Bannon) writes:
>brian@vuse.vanderbilt.edu (Brian Antao) writes:
>>an instance variable. The suggested feature would be, that the compiler/
>>interpreter, by default inserts these methods corresponding to each instance
>>variable specified in the Class definition. Each time the Class definition is
>>recompiled, the appropriate access methods should be added/deleted if any
>>instance variables are added/deleted. One could also argue for a similar
>>feature to also support class variable access. 
>
>This would not be difficult to add, just aesthetically unpleasant.  Why?
>One of the primary ideas behind 'objects' is the encapsulation of data with
>the code that manipulates it.  Why is this good?  If used properly, it 
>minimizes the 'side-effects' that can occur with other programming paradigms.

There is a limitation in smalltalk, in that one cannot explicitly classify
instance variables to be public or private. If this feature  exists, such as
in C++, then the access methods would be generated only for those instance 
variables designated as public, and need access methods anyway. This would
satisfy the encapsulation constraints as well.

>In SmallTalk, no object can manipulate another's state unless you 
>'do it on purpose',  by constructing the access methods to do so.
>If access methods were automatically generated for every private variable, 
>then this breaks down; every object can diddle with the state of every other.

An object would be able to access the state of another object only if it
has been instructed to do so. ie via explicit coding. In such cases you need
some aspects of an object that is maintained in an instance variable. Th only
way to acces and update/modify the state is via an access method.

>Yes, frequently you need to write several access methods for several private
>variables of an object, but if you are finding that you need to make ALL of
>your instance variables public, then perhaps you need to rethink your design.

At the current status of smalltalk, there is no way of seperating private and
public internal (instance variables), hence the default notion of access 
methods for all. 

Which also bring up the issue, DO we need to distinguish Private and Public
instance variables in smalltalk ?,


-- 
Brian Antao,  Dept. of Electrical Engg.,     |INET: brian@vuse.vanderbilt.edu
Vanderbilt University, Nashville, TN, USA 37235 
Disclaimer:      "Artificial Intelligence" - an oxymoron ? 
-------------------------------------------------------------------------------