Newsgroups: comp.lang.smalltalk
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!m.cs.uiuc.edu!cs.uiuc.edu!voss
From: voss@cs.uiuc.edu (Bill Voss)
Subject: Re: Access methods - New feature ?
In-Reply-To: knight@mrco.carleton.ca's message of Tue, 23 Apr 1991 01:00:26 GMT
Message-ID: <VOSS.91Apr23194435@laslo.cs.uiuc.edu>
Sender: news@m.cs.uiuc.edu (News Database (admin-Mike Schwager))
Nntp-Posting-Host: laslo.cs.uiuc.edu
Organization: Typed Smalltalk Group, Dept of Comp Sci, Univ of IL in Urbana.
References: <1991Apr21.221149.8057@vuse.vanderbilt.edu>
	<VOSS.91Apr22113638@laslo.cs.uiuc.edu>
	<VOSS.91Apr22183834@laslo.cs.uiuc.edu>
	<1991Apr23.010026.25098@ccs.carleton.ca>
Date: 23 Apr 91 19:44:35
Lines: 78

I wrote a few messages ago:
 >When I call another class's access methods, I almost always find I should have
 >opened another browser, and started adding methods to the other class instead.

Alan Knight argues the following are counter examples
>     Point     x, y
>     Rectangle origin, corner, extent
>     Line      slope, or Line coefficients

>   All of these represent information that I might reasonably want to
>   know about an object, but they may easily correspond to pieces of
>   the representation.  Then again, they may not, and that's the point of
>   encapsulation.  

	Point is a particular favorite of mine, because I goofed BIG
	using class Point when I started using Smalltalk.  Back then I 
	was very very new to Smalltalk, and very very timid/reluctant to 
	alter/extend the existing code.

	So I was writing something which needed a Point.  Hey I thought to
	myself, I'll bet a class Point already exists.  Search for "Point"
	yep, sure does.  Lets see how this works....ah ACCESSING methods
	x x: y y: thats great.  I understand these methods.  I can read and 
	set the x and y values for a point, just what I need.  Wow they were
	right, you can reuse code in Smalltalk.  This is great.  :-)

	For the next few weeks, if I needed the distance between two
	points, I'ld go
		x1 <- point1 x.
		y1 <- point1 y.
	and so forth, plugging my temporary variables into the distance 
	formula we learned in High School.  I was using Point as a simple
	two element array.

	Obviously I should have been using "point1 dist: point2." instead.
	However, NOT because dist: already exists.  I should have been using
	dist: EVEN IF I NEEDED TO WRITE IT.  Unlike my code, the "dist:"
	method was in the right place.  It needs to know about the internals
	of a Point, so it is located INSIDE the class Point.  The method "dist:" 
	is in my opinion a very GOOD example of how to do things.  However,
	the class Point is not such a good class.  The Point class seems to
	encourage programmers to break encapsulation.

Exercise 1:  Make a wild guess as to how frequently code in the Smalltalk-80
	     image needs to determine the distance between two points.
		invoke "senders" on the method "dist:"
		invoke "senders" on the method "x"
	     How are programmers doing it?

Exercise 2:  A new faster way of computing the distance between two
	     points has been found.  Change all existing code in the
	     Smalltalk-80 hierarchy to use the new method.

Exercise 3:  Comment on the results of Exercise 1 based on your experience
	     in Exercise 2.

	So I have shown that accessing the x and y instance variables
	of class Point MAY be wrong.  Hopefully we can all at least agree
	on that much?  :-)
-------------------------------------------------------------------------------
	Now is it ALWAYS wrong to use access methods?  
	I do NOT contend that it is ALWAYS wrong.
	I think it must be judged on a case by case basis.
	However, I do contend that it is USUALLY wrong.

	I have not yet seen anyone post a good counter example.
	They say this or that instance variable is "obviously"
	an exception, but they don't show WHY they need to
	access that particular variable.  Without knowing WHY
	I can't tell wether they are correct or not.

	(Hmm looks like rain... I might even get flooded now. ;-)
-------------------------------------------------------------------------------
	The next obvious question is "What do you do instead?"
	;-) So glad you asked. ;-)

	It is my contention that instead of using something like

