> > I'm not sure you can get rid of the shared state so easily, however.
> > Consider a Cell object, with two messages #set: and #get.  The cell's
> > instance variable can only be accessed directly by Cell itself, but
> > because of these accessor methods, the result is the same as if the
> > variable really was directly accessible.
> 
> No it's not. It's entirely different. The critical issue is "simultanous"
> access (as Ken pointed out). If you allow simultanous access you cannot
> guarantuee that the object is in a consistent state. As long as it is,
> there's not problem with #get or #set: - but if you send any of these
> _while_ some other thread is modifying the object it may just be in some
> inconsistent state. It's basically transaction handling.

I don't follow.  Let me put it this way: how do you know when your
messages are transactions?  If your updates are too fine-grained, then
you still have problems.


> 
> 	someAccount setAmount: someAmount getAmount + delta.
> 
> (modifying the object from the outside) is doomed to fail. You _must_
> implement something like:
> 
> Account>>addAmount: delta
> 	amount := amount + delta.


Why can't I?  Can't I write a #getAmount request?  Can't I write a
#setAmount: request?  These are both useful in other contexts, after
all.  So what's to stop me from combining them?

A real example of this is in Scamper.  The sequence is (rephrased in
terms of message-passing; it actually uses SharedQueue's):

	1. scamper says: "downloader startDownloading: url"

	2. " ... scamper displayes 'downloading' -- *assuming* the downloader
is in a downloading state"

	3. downloader says:  "scamper documentArrived: doc"

	4. " ... scamper displays 'done' -- assuming the downloader is no
longer downloading"


The status line is only correct based on assumptions about what the
downloader object is doing.  In fact, if other objects do start talking
with the downloader object, then the assumption can be broken.  That
seems okay to me.  In fact, I don't see a simple way here to have pure
transactions -- the whole point is that the downloader does some
well-defined and predictable thing and then comes back later to continue
an interrupted discussion.  The objects are *collaborating*, and some of
the assumptions they make about each other involve their current state.


Overall, for writing threaded programs, I really am sold on using
message-passing instead of mutexes plus shared stated.  In fact, all two
times I've written threaded code in Squeak, I used a SharedQueue to
communicate between the threads.  However, this style only makes things
easier, not foolproof.  It's still up to the programmer to design a good
set of messages, and the programmer can certainly screw up.


-Lex