Newsgroups: comp.lang.smalltalk
Path: utzoo!utgpu!cunews!helmut!eat
From: eat@helmut.scs.carleton.ca (Eric Arseneau)
Subject: Re: Access methods - New feature ?
Message-ID: <1991Apr24.184323.8018@ccs.carleton.ca>
Sender: eat@helmut (Eric Arseneau)
Organization: School of Computer Science, Carleton University, Ottawa
References: <1991Apr21.221149.8057@vuse.vanderbilt.edu> <VOSS.91Apr23201829@laslo.cs.uiuc.edu>
Date: Wed, 24 Apr 1991 18:43:23 GMT

In article <VOSS.91Apr23201829@laslo.cs.uiuc.edu>, voss@cs.uiuc.edu (Bill Voss) writes:
|> 
|> 	For some reason GNUS/nntpd keeps dropping the tail of my posting
|> 	with the message "writing to process: no more processes, nntpd"
|> 	So here is that final section, ONE MORE TIME.
|> -Bill
|> -------------------------------------------------------------------------------
|> 	The next obvious question is "What do you do instead?"
|> 	;-) So glad you asked. ;-)
|> 
|> 	It is my contention that instead of using something like
|> 
|> 			x1 <- point x.
|> 			y1 <- point y.
|> 			anObject myThingX: x1 Y: y1.
|> 	or in one line
|> 			anObject myThingX: (point x) Y: (point y).
|> 
|> 	in those cases where you legitimately need to know x and y,
|> 	outside of Point, you should instead write a Point method:
|> 
|> 		doMyThingOn: anObject
|> 
|> 			^anObject myThingX: x Y: y.
|> 
|> 	I consider this CLEANER, more READABLE, more MAINTAINABLE, and
|> 	much harder to abuse than a straight ACCESS technique.
|> 
|> 	The fact that it usually involves both less programmer typing, 
|> 	and fewer runtime message sends is a nice bonus.
|> 
|> -Bill Voss <voss@cs.uiuc.edu>


This goes without saying.   But saying that access methods are a no-no
is absolutely wrong.  This is easy to show by simply stating that a user
of an object has absolutely no way to know what is being returned, an 
instance variable or a function of some other objects.  This is what 
encapsulation gives you, and it suppors CLEANER, READABLE and MAINTAINABLE
as the users do not know ho they are implemented.

If a function makes sense to do on a particular object, then you add it to
that object's class.  If myThingOn: is something that is general for a point
then it is totally obvious that you shoudl implement it under Point, but
this does not rule out access methods.  If at a later point I change the 
representation of my objects, then I still have to provide the accessing
methods I had before, so if a method used to return an instance variable, and
it no longer does, who's to know the diference.  The point is that the method
still has to be supported in the new representation because it was part ofg
the public interface to your objects before, and you're still repsonsible
for supporting all of the previous operations, even if the representation
chenages.

When I am writing a class, I write an access method for all of my instance
variables, making some private and some public.  Instead of referencing
an instance variable directly, I will send myself the accessor message`
to get it's value.  That way when I change the representation of my class
later on, all of my other operations will still work as long as I still
support the old accessor messages, but mapped to something appropriate.
This makes it much easier for the implementor (not the user) of a class
to change his represenation and still have things working somewhat, maybe
not as efficient as it should be, but he can go back later and replace the
senders of the old accessors and update them to the new representation.

THE POINT:  Acessor methods are definitely OK !!!
