My work with the Islands package and the subsequent discussion has made me 
realize a very important point:

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 (such as it is done in FarRef).

Consider class Rectangle and let's see if it could be a BabyComponent that 
encapsulates its member objects.

There are two "member objects" in an instance of Rectangle: origin and corner.

There is only one method that sets these variables directly: 
Rectangle>>setOrigin: topLeft corner: bottomRight

I can interrogate the rectangle by messages such as topLeft, topRight, 
etc... They all return new Points; a statement such as rect topLeft x: 200 
does not change the rectangle - it merely changes the returned point.

A very different message is origin. The statement rect origin x: 200 DOES 
change the rectangle because origin returns the instance variable itself.

The Rectangle>>origin 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.

The BabyComponent is a trap-removing device. There is a cost; rect origin 
is faster than rect upperLeft.

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 left: anInteger.

I found 333 senders of origin 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...

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?

I've got a new and important issue on my list, thanks to the Islands 
implementation.

--Trygve


-- 

Trygve Reenskaug      mailto: trygver at ifi.uio.no
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20050924/2a406e9e/attachment.htm