From: shugo@...
Date: 2016-09-09T03:08:44+00:00
Subject: [ruby-core:77227] [Ruby trunk Feature#12086] using: option for	instance_eval etc.

Issue #12086 has been updated by Shugo Maeda.


Charles Nutter wrote:
> > Yes, you'll get unexpected results in this case.
> 
> I think you'd get unexpected results in my original case too, wouldn't you? Both of those two blocks still have the same prev_cref, which is where the refinements collection comes from. Am I wrong?

Ah, I was wrong...in both cases you get *expected* results because cref is newly created by each call of instance_eval(using:).

I tried the following code, and Thread X always returned "refined by X" and Thread Y always returned "Y".

```ruby
module X; refine Fixnum do; def +(x); "refined by X"; end; end; end

module Y; refine Fixnum do; def +(y); "refined by Y"; end; end; end

def eval_with_my_refinements(refinements, &block)
  instance_eval(using: refinements, &block)
end

b = Proc.new { 100.times { p [Thread.current.name, 1 + 1]; Thread.pass } }
[
  Thread.new { Thread.current.name = "X"; eval_with_my_refinements(X, &b) },
  Thread.new { Thread.current.name = "Y"; eval_with_my_refinements(Y, &b) },
].each(&:join)
```

> > It's true that cache is invalidated by instance_eval(using:), but global method caching has been improved in MRI, and I don't know how different compared to JRuby.
> 
> What is the impact of that invalidation? I am not familiar with how MRI globally invalidates these days and how it reduces the impact.

In MRI, global cache is invalidated per class.

> > I don't know it should be applied to code used with the new features.
> 
> But if I have chosen not to use this feature, for the performance of my application, I'll also have to check every library I depend on to see if they use the feature. If I don't, such a library might impact the performance of my entire application. I don't think we want that.
> 
> So summarizing my concerns up to this point:
> 
> * The current design is not thread-safe. It might be possible to make it thread-safe at the cost of additional complexity, which may mean further reducing performance. (design issue)
> * If any code in the system uses the current implementation of this feature, that impacts the performance unrelated code by invalidating global caches. (implementation issue)
> * All blocks everywhere in the system will now be suspect; you will not be able to tell what method will be called unless you control everywhere that block will be passed (usability issue, in my opinion)

Anyway, I understand your concerns.  Thanks for your feedback.



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

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