From: shyouhei@... Date: 2016-07-20T02:42:56+00:00 Subject: [ruby-core:76463] [Ruby trunk Feature#12086] using: option for instance_eval etc. Issue #12086 has been updated by Shyouhei Urabe. We looked at this issue at yesterday's developer meeting. About performance, Matz wanted to hear opinions of JRuby implementors. It might be true that it is negligible for the MRI, but situation might be different for others. ---------------------------------------- Feature #12086: using: option for instance_eval etc. https://bugs.ruby-lang.org/issues/12086#change-59708 * 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 . 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: