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