From: headius@...
Date: 2016-09-07T12:43:35+00:00
Subject: [ruby-core:77208] [Ruby trunk Feature#12086] using: option for	instance_eval etc.

Issue #12086 has been updated by Charles Nutter.


I'll echo Tom's comments...this is dynamically-scoped refinements all over again, which we discussed heavily. There's two big reasons why this is a risk:

* Performance. We decided that refinements would be lexical *only* in order to limit the impact of refinements on non-refined code. There's no way to treat a block as non-refined code since it might be refined at any time. I am interested to see how MRI can refine any block anywhere without impacting non-refined performance.
* Readability. Now EVERY block in the system could potentially get refined. You will NEVER again be able to look at a piece of code in a block and know it's calling the methods you want it to call.

Back when we were first putting refinements together, we all agreed to keep them lexical. This is not lexical anymore.

I guess I'm very confused why this feature is needed for the DSL example. rspec implements a very similar DSL and does not use refinements today.

We could make this work and still keep refinements lexically scoped if we allowed using to happen within a block:

```ruby
require "radd_djur"

calc = RaddDjur::Grammar.new(:expr) {
  using RaddDjur::DSL

  define :expr do # refined call to "define"
    [:int, "+", :int].bind { |x, *, y|  # refined "bind"
      ret x + y # refined "ret" and "+"
    } / # refined "/"
    [:int, "-", :int].bind { |x, *, y| # etc
      ret x - y
    }  
...
```

I can't recall why we wanted to avoid "using" within a block or method body.

I still believe this should be a lower-level language feature, as a keyword or similar. The more dynamic you make it, the more unpredictable and unreliable code is going to become.

I'll have a look at the proposed implementation.

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

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