Capabilities in Squeak (attn: Lex Spoon and friends)

Andreas Raab andreas.raab at
Tue Oct 17 03:42:25 UTC 2006

Robert Withers wrote:
> Secondly, FarRefs and promises don't understand all the base protocol 
> that a normal object understands so many of the tools in the image don't 
> deal well with eventual objects. 

Actually, I consider this a fatal bug of FarRefs which I finally solved 
in the Croquet version (TFarRefs). In Croquet, we do not hide the 
difference between "near" and "far" objects simply because we cannot 
hide the difference in the transport protocol utilized. Since all 
replicated messages require a roundtrip to the router before they are 
executed you can kiss the idea of a "transparent" handling goodbye, even 
with promise pipelining and all the other tricks. It's simply not 
possible and trying to hide the difference makes the problems much worse 
than admitting the differences and giving people a way to deal with it. 
One of the things that gets relevant in a hurry for example is that when 
you're behind a DSL link your upstream bandwidth is *extremely* limited 
and you simply need to know which messages you send where and when and 
why upstream. And that means the programmer needs to see when things go 
over the wire, these messages simply must be explicit. [My apologies go 
to both MarkM and MarcS who consistently told me that this would be the 
case but until I had the chance of looking at "other people's code" I 
hadn't realized how big both the conceptual as well as the practical 
mess is if you try to "make those differences go away"].

So, today when you use Croquet and have a far ref you *must* send 
explicit future messages. TFarRef itself is a plain old Object subclass 
which means printing, inspecting and debugging works just fine. And I am 
in the process of doing precisely the same for Tweak which will 
dramatically simplify a lot of stuff that was just unbelievably awkward 

   - Andreas

More information about the Squeak-dev mailing list