[ruby-core:76326] [Ruby trunk Feature#12086] using: option for instance_eval etc.

Issue #12086 has been updated by Shugo Maeda.


Nobuyoshi Nakada wrote:
> Shugo Maeda wrote:
> > It looks cool, but there are two problems here:
> > 
> > 1. We have to write `using RaddDjur::DSL` explicitly.
> > 2. Refinements for DSL is available out of the grammar rules.
> 
> These seem irrelevant to `instance_eval`.

So, do you have another solution?

> > If `instance_eval(using: refinement)` is introduced, RaddDjur::DSL can be activated
> > only in the block given to `RaddDjur::Grammar.new`, and these two problems will be solved.
> > 
> > Note that `instance_eval` and refinement activation have to be done atomically in this case.
> > That's why I proposed this feature as a new option of `instance_eval`.
> 
> I don't think that a proc is evaluated under unpredicable context is a good idea.
> `using(refinement, &block)` feels even better than it.

I don't catch your point.
`using(refinement, &block)` can also be used to evaluate a proc under unpredictable context,
can't it?

I think features using instance_eval(using:) are extraordinary, and used refinements
should be described in documentation.


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

* 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:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>