On Tue, 25 Oct 2005, nobuyoshi nakada wrote:

> Hi,
>
> At Tue, 25 Oct 2005 07:20:17 +0900,
> Daniel Amelang wrote in [ruby-core:06375]:
>>> It is not thread-safe.
>>
>> Maybe, care to explain why?
>
> (class<<self;self end).send(:define_method, :__inst_eval_temp__, block)
> # another thread may intercept here.
> result = __inst_eval_temp__(*args)
>
>> I assume that you don't expect multiple threads to access the same object.
>> It is generally assumed that you should guard your objects. E.g. noone
>> expects a string object to handle #size properly while another thread calls
>> #slice!. But you are probably referring to something else...?
>
> If it is guraded outside, thread-safeness in a method is not
> important, or even redundant.  In general, the word
> "immediately" makes no sense with multi-threading.  Atomicity
> is important.
>
>> I guess I should have made it clearer: I'm not proposing to add this
>> _implemenation_ to the ruby language, I'm asking if the proposed _behavior_
>> would be useful.
>
> I know, and don't intend to offend you at all.  Just a nitpick.

not freeze safe, but thread safe:

   class Object
     def evaluate *a, &b
       klass = Class === self ? self : self::class
       m = "____evaluate____#{ Thread::current.object_id }____#{ rand 666 }____#{ rand 42 }____"
       klass.module_eval{ define_method m, &b }
       begin
         send m, *a
       ensure
         klass.module_eval{ remove_method m } rescue nil
       end
     end
   end

i suppose this approach cannot be made to work with frozen objects.

-a
-- 
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| anything that contradicts experience and logic should be abandoned.
| -- h.h. the 14th dalai lama
===============================================================================