From: headius@...
Date: 2016-09-07T13:59:54+00:00
Subject: [ruby-core:77209] [Ruby trunk Feature#12086] using: option for	instance_eval etc.

Issue #12086 has been updated by Charles Nutter.


Is this thread-safe? Would it be possible for two threads to refine the same block in different ways and step on each other?

I see that instance_eval (yield_under) creates a new cref for each instance_eval call...but if I'm reading it right it shares the refinements collection with prev_cref, right? So it seems to me a given block could have its refinements change across threads.

rb_using_module impacts the method cache. Not sure if that's a concern or not, but one thread doing dynamic refinements could impact *every* unrefined call on other threads, right?

Cross-thread refinement changes could impact work MRI folks are doing on optimization and deoptimization.

I have other questions to understand how MRI reduces the impact of refinements on unrefined code...

Does MRI throw away the block's method cache every time instance_eval is called? Method caches can be se per-activation, rather than just sourced from the iseq?

Does MRI currently check for refinements before every method call?

----------------------------------------
Feature #12086: using: option for instance_eval etc.
https://bugs.ruby-lang.org/issues/12086#change-60424

* Author: Shugo Maeda
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
Currently refinements can be activated only in toplevel or class/module definitions.
If they can be activated in block-level, it's useful to implement internal DSLs.

How about to add a new option using: for Kernel#instance_eval and Moule#{class,module}_eval?

```ruby
module FixnumDivExt
  refine Fixnum do
    def /(other)
      quo(other)
    end
  end
end

p 1 / 2 #=> 0
instance_eval(using: FixnumDivExt) do
  p 1 / 2 #=> (1/2)
end
p 1 / 2 #=> 0
```

Proof-of-concept implementation is available at <https://github.com/shugo/ruby/tree/eval_using>.

In my previous proposal before Ruby 2.0, refinements used in a class or module are
implicitly activated by instance_eval and class_eval, but now I think it's better to
explicitly specify refinements to be activated.

Considerations:

* In the PoC implementation, refined methods are not cached inline, and thus it decreases
  the performance of refined method call.
  If there is a way to guarantee that blocks never be evaluated in different environments,
  refined methods can be cached inline.
* {instance,class,module}_exec cannot be extended in the same way, because they take arbitrary
  arguments and there's no way to distinguish an option hash from the last argument hash.




-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>