From: shugo@... Date: 2016-07-08T08:02:07+00:00 Subject: [ruby-core:76317] [Ruby trunk Feature#12086] using: option for instance_eval etc. Issue #12086 has been updated by Shugo Maeda. Yukihiro Matsumoto wrote: > I like the idea, but I understand this makes implementation harder (especially for performance). Speaking of performance, inline cache cannot store refined methods because the same block can be executed with different refinements with this feature. However, there is no performance degradation for code without refinements. ---------------------------------------- Feature #12086: using: option for instance_eval etc. https://bugs.ruby-lang.org/issues/12086#change-59553 * 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: