Message-ID: <328A849C.FB3@parcplace.com>
Date: Wed, 13 Nov 1996 18:31:56 -0800
From: Brad Horstkotte <brad@parcplace.com>
Organization: ParcPlace-Digitalk, Inc.
X-Mailer: Mozilla 2.0 (Win95; I)
MIME-Version: 1.0
Subject: Re: Accessing instance variables
References: <3289FC37.35DA@csu.edu.au> <3289F08B.1106@iconcomp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Newsgroups: comp.lang.smalltalk
Lines: 43
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!portc01.blue.aol.com!portc02.blue.aol.com!howland.erols.net!math.ohio-state.edu!uwm.edu!daffy!uwvax!news.heurikon.com!news.dpc.net!novia!nntp2.rmci.net

Bill Gooch wrote:
> 
> Phillip Swain wrote:
> > ....
> > 1. If you want to access an instance variable from within the object
> > where they are stored then you can access them directly
> >         ...
> >
> > 2. If you want to access an instance variable from within the object
> > where they are stored then you should access them via a "getter" or
> > "setter"
> >         ...
> >
> > The argument for the first option is that Smalltalk seems to do it all
> > the time in its methods, whereas the argument for the second option is
> > that if you ever need to change the way you access an instance variable
> > you only need to change the getters and setters, not any other methods.
> 
> I am a strong believer the second approach, because it
> breaks the dependency between methods (other than getters
> and setters) and instance variables.  One can then change
> instance variables - even remove them and make the values
> derived - without affecting the bulk of the code.

The fact that "Smalltalk seems to do it all the time in its methods" is more an issue of historical 
significance than "style": if you look at PPD's Smalltalk products (Visual Smalltalk & VisualWorks), for 
example, you should see a trend toward more and more exclusive usage of accessor methods (both publicly 
and privately) in newer code, and in updated older code.  The primary reason for doing so is that it is 
easier to maintain a stable public interface, while retaining the ability to change data representation 
internally without affecting client code (assuming client code also uses the public accessor methods) - 
especially important when client code subclasses your code.

Brad
