Robert Klemme wrote:
> S.Z. wrote:
>> undef :to_s, :taint, :clone;
>> Now method_missing() can operate.
>And which method do you invoke then if you undefined all those methods?
If I invoke to_s() on Sync object, then method_missing()  will be
called because to_s() has been undefined for Sync class.
method_missing() can do all I want to be done.

Robert Klemme wrote:
> S.Z. wrote:
>> Any transaction on an object can be treated as a single method call.
> Certainly not!  It might in a many scenarios but there's also a lot
> scenarios where this does not apply.  This statement as a general
> statement is wrong.
Would you show an example in which this does not apply?

Robert Klemme wrote:
> S.Z. wrote:
>> Transaction's body can be known only at runtime; but it is not a
>> problem in Ruby.
> What are you trying to say here?
Excuse my poor English.
Transaction is not a method call, rather a context for several method
calls.
But, if we can put these calls to single batch and invoke it then
transacton is just a method call, except for begin/commit semantics.
In Ruby we can easily create such a batch.

Robert Klemme wrote:
> Built in sychronization of every
> method is pointless because you never get the class without
> synchronization overhead.
It is obvious.
Rather having an ordinary object I need to construct the synchronized
one without the use of errorprone external mutexes and randevous.
As the first step, I have created Sync class to hold the object and the
sync semantics.
In the simplest case of read/write unordered buffer only per-method
synchronization is needed and therefore Sync class can solve the task.

-- many thanks twice