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