<html>
<body>
My work with the Islands package and the subsequent discussion has made
me realize a very important point:<br><br>
<i>It is relatively easy to pass incoming messages through a gatekeeper
such as Islands/farRef. It is much harder to handle the returned values
in a proper manner </i>(such as it is done in FarRef)<i>.<br><br>
</i>Consider class <i>Rectangle </i>and let's see if it could be a
BabyComponent that encapsulates its member objects.<br><br>
There are two "member objects" in an instance of Rectangle:
origin and corner.<br><br>
There is only one method that sets these variables directly:
<b>Rectangle>>setOrigin: <i>topLeft </i>corner:
<i>bottomRight<br><br>
</i></b>I can interrogate the rectangle by messages such as
<b>topLeft</b>, <b>topRight</b>, etc... They all return new Points; a
statement such as <b>rect topLeft x: <i>200</b> </i>does not change the
rectangle - it merely changes the returned point.<br><br>
A very different message is <b>origin</b>. The statement <b>rect origin
x: <i>200</b> </i>DOES change the rectangle because <b>origin </b>returns
the instance variable itself.<br><br>
The <b>Rectangle>>origin</b> method violates the encapsulation by
revealing the implementation. This is not acceptable in a BabyComponent
because the client shall not be forced to study the implementation to
avoid being trapped. I do not often take the time to read my Squeak code
right down to the innermost method. I do, of course learn the traps from
personal and bitter experience so that I can avoid them in the future.
<br><br>
The BabyComponent is a trap-removing device. There is a cost; <b>rect
origin</b> is faster than <b>rect upperLeft</b>.<br><br>
My immediate reaction to this renewed study of Rectangle would be to
remove the origin message from its public interface and consider adding
messages such as <b>left: <i>anInteger</i></b>. <br><br>
I found 333 senders of <b>origin </b>in my current image. Most of them
are probably read-only. But there could, somewhere, be a smart method
that used it to modify the rectangle itself. There could even be a
subtle bug somewhere...<br><br>
The question is if it would be an advantage to group Squeak objects into
components with defined public interfaces and without revealing the
member objects. If the answer is yes: Are there examples where it is
inappropriate?<br><br>
I've got a new and important issue on my list, thanks to the Islands
implementation.<br><br>
--Trygve<br><br>
<x-sigsep><p></x-sigsep>
-- <br><br>
Trygve Reenskaug mailto:
trygver@ifi.uio.no<br>
Morgedalsvn. 5A
<a href="http://heim.ifi.uio.no/~trygver" eudora="autourl">
http://heim.ifi.uio.no/~trygver<br>
</a>N-0378
Oslo Tel:
(+47) 22 49 57 27<br>
Norway<br>
</body>
<br>
</html>