That's the point: you *don't* have synchronized access to
any object.
All you have is messages. Think of it as an OO view of processes. You can't see what's inside, you can only ask the process
to do things
on your behalf.
Again, a question raised: how to ensure that messages are passed in correct order and make sure that messages are delivered? Now lets look inside: to make it working properly, you need to implement a message queue. And queue means that you must make an 'enqueue' and 'dequeue' operations synchronized. And that's exactly what i mean: even if you hide the concurrency problems from the eyes of developer, this is not means that problems are gone: now you have to deal with them by own. If you know another way(s) how to make proper message passing scheme without using synchronized object (such as queue), i am all ears.
-- Best regards, Igor Stasenko AKA sig.
1. For the correct order: I understand that Erlang is open so, to some point, nothing stop us from looking that how-tos on how Erlang's VM makes the message passing in correct order right? Seems to me that somehow they solved that question and probably we can study how assimilate that virtue. 2. For ensuring messages sends: "send and pray"
That way when a smalltalk's erlangized message send is in a process that terminates it should end with some cause for the act of finish. Maybe this will allow for instance to implement DNU: the VM don't find a proper method in the object to receive that message so it terminates the process stating that as cause.
Cheers,
Sebastian