Capabilities in Squeak (attn: Lex Spoon and friends)
Andreas Raab
andreas.raab at gmx.de
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
before.
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|