[comp.lang.smalltalk] Access Methods - Summary

brian@vuse.vanderbilt.edu (Brian Antao) (04/27/91)

The discussion on Access methods has been very exciting, Thanks to all
who participated, and the silent observers too !, it has been an
interesting and somewhat enlightning exchange.  At this point it seems
appropriate to summarize the notable points. This summary may not be complete,
so if you feel that I have missed out anything important feel free to
follow up.

Here goes,

1. Personally, totally disagree with the notion that the use of access methods
is a faux-pas. ( No intent to flame Bill the purist !)  Here's a justification,
Consider a case where you have a hypothetical complex object, whose 
behavioral state is modeled via a number of instance variables. An event
triggered by another object sending a message (not an access method !)
causes the object to exhibit a certain behavior marked by a change of
state. This causes the various instance variables to be updated, internally
of course. One could have a set up such that these cahnges are propagated
to dependent objects. subsequently during the course of execution, some
object would need to access some of the states, these states can be
interpreted as the public states of the object that it exhibits to the rest
of the object world. The only way of obtaining these public states is via
access methods. So in such instances when certain facets of an object are
public, the use of access methods to make these available is only natural.

2. An access method is essentially the simplest form of a method that simply
returns an instance variable value, in contrast to a more complex method that
returns the result of a more elaborate computation. {this distiction
is made without any paradigmatic implications !}. The sender of the method
is not necessarily aware of this fact that the message invokes a call to
an access method, or a more complex method. An this is what encapsulation
is all about !. The external world is only aware of the communication
(message) protocol, and not the implementation of the method. In fact
instance methods could be used to cache intermediate results of a
computation that maybe expensive to perform in response to each message
(See point 1, above, where only a major event causes the object to undergo
a complete change in its current behavioral state.)

3. The original posting for an automatic mechanism that generates
access methods for each instance variable, may not be wholly appropriate.
Such a mechanism would be an useful programming aid. However a better
structured stratergy that allows a user to designate variables for which
access methods have to be defined would satisfy encapsulation requirements.
Another useful bookkeeping/error checking feature would be to have the
compiler recognize when one of these instance variables is deleted,
and appropriately delete the associated access methods. 

4. Public v/s Private variables: Since Smalltalk-80 does not have an
explicit mechanism to specify public methods, all variables that
hace access methods defined, may be interpreted as being "public" in
nature. Also one may argue for the message protocols to have some
functionality, rather than serve only to categorize methods, such has
imposing privacy on the designated methods. Another case for ensuring
encapsulation ?, 




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