Hi.

I think that wether anObject implements its messages using accessors or
just referencing variables on the fly is the same, provided that
anObject is properly built and designed. I also think that even more
important that the implementation is the protocol design, in which the
accessors are included. Since Smalltalk doesn't enforce message privacy
(something like #willNotAnswer: aMessage), marking accessors as private
does not really exclude them from the protocol.

Assuming for a minute that instance variables should have read/write
accessors, in the Interval case this would allow mutators, which is more
than accessors. I don't think mutators are desirable for Interval,
although I think accessors are fine. So, the read/write pair is not
always desirable.

Some other times, even reading accessors are not desirable. For
instance, consider a BinaryTree. There are many ways to implement a
BinaryTree. Then, BinaryTree is the abstract class and its subclasses
implement the BinaryTree protocol in different ways. BinaryTree could
define an instance variable named tree, in which every subclass would
store the nodes, or the information of the nodes, or whatever. Access to
this local variable should not be allowed, not even for reading, if the
coherency of the BinaryTree is to be ensured (aTree nodes become: nil).
The only way to do this is by using immediate references to the tree
instance variable.

For Trees, I have built an abstract class named AbstractTree, with
subclasses implementing its most basic and primitive protocol. The rest
of the protocol is implemented at AbstractTree. The remaining 14
methods, 5 of which are private, do all the low level hard work like
adding/deleting/finding nodes, tree pruning and grafting, and tree
maintenance. Some trees store nodes with linking information, some
others like one kind of BinaryTree just store the nodes' information.
The only methods that use immediate access to the instance variable are
the five private methods that must be implemented for each concrete
subclass of AbstractTree.

In short, I think that accessors/mutators depend first on the protocol
design. In addition, I think that if each object is the only entity that
can see its instance variables, it is automatically entitled to make use
of that knowledge. Unless design dictates against it, as in lazy
initialization or any other mechanism, I think that plain accessors that
are just ^instVar are somewhat redundant once the object protocol
implementation model is clear.

Andres.