SharedSmalltalk (was: A Question about Croquet's Philosophy...)
rwithers12 at attbi.com
Sun Jan 12 02:45:52 UTC 2003
On Saturday, January 11, 2003, at 05:10 PM, Anthony Hannan wrote:
> Definitely, I only defined a capabilities-based object model for
> classes, and haven't implemented anything yet. We could implement it
> your framework. It looks like you are implementing the secure
> communications needed. This is great.
yes, the secure comms is fairly non-controversial and useful, so it
hasn't been a complete waste of time. :) The rest of it is
potentially very controversial. I do have a mixin redirector, that
allows you to do meta-level behavior compositing. It is an area I have
barely explored and I hope an implementation, like metaclassTalk or
traits, along with my redirectors and eventual sending, could
complement each other.
> Eventually sending is cool too. Although, it can be tricky when
> have side effects. For instances:
> "<xxx means eventual send of xxx"
> a <printOn: stream.
> b _ stream contents.
> If the eventual send of printOn: completes after "stream contents", b
> will be missing a's printString. What is your stance on these delayed
> side-effect cases?
That's a good question. It's really the heart of the matter, isn't it?
almost always (but not quite) the #contents will be evaluated before
the #printOn:. IMHO, implementing an implicit execution barrier not
the best course of design, although I am ready to be convinced
otherwise. I think it will be too complex and restrictive, and prone
Note that I do *not* use special syntax to cause an eventual send to
occur. I send messages to create controlled references, which send
messages differently. Send #eventualRef to any object to get into an
eventual sending regime of your control flow. there will be mechanisms
to drop back into immediate sending regime.
This means that we allow this disco-ordination to occur. I will assert
that It is perfectly valid, since objects are asynchronous and shared,
to have race conditions in reading and writing state. While not
non-trivial, transactions would probably be sufficient to provide
rollbacks, should the unexpected happen.
I expect that with the power this mechanism offers, there are ways to
shoot yourself in the foot. To provide means of explicit coordination,
there are methods like #whenResolved:, #ifError: (which should be
changed to #on:do:), and #delayFor:, which you can send to an reference
(immediate or eventual, resolved or promised). I think that something
like Lex's #stabilize would provide a way for the calling script to
block until promise resolution - or just send #immediateRef to any
eventualRef; it would be symmetric.
Aside from one item, this mechanism is entirely behavior based. From
creating new controlled references, to invoking and coordinating the
results, it is just message passing. The one item that isn't is
identity. Being able to control identity in this environment is very
It is ultimately an issue of transparency. This framework is not going
to provide a transparent distributed objects system. My philosophy is
this: you, as a developer, should know what and how you are dealing
with objects. The what stays the same, a POLA (principle of least
authority) reference to an object that has an identity and behaviors I
can invoke. The how of interaction can change, allowing different
these kinds of objects can do the unexpected. they can change and be
unreliable, like any system. Network and system failures can prevent
computations from completing. Therefore, the concept of a broken
reference is introduced. Any reference can be "smashed", which will
propagate the failure to the promises of subsequent invocations.
More information about the Squeak-dev