SharedSmalltalk (was: A Question about Croquet's Philosophy...)

Robert Withers 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 
> in
> 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 
> methods
> 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 
to confusion.

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 
important.

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 
execution semantics.

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.

cheers,
rob




More information about the Squeak-dev mailing list