[#76442] [Ruby trunk Feature#11741] Migrate Ruby to Git from Subversion — naruse@...
Issue #11741 has been updated by Yui NARUSE.
3 messages
2016/07/19
[#76515] [Ruby trunk Bug#12610] webrick: protect from httpoxy — nagachika00@...
Issue #12610 has been updated by Tomoyuki Chikanaga.
3 messages
2016/07/22
[ruby-core:76463] [Ruby trunk Feature#12086] using: option for instance_eval etc.
From:
shyouhei@...
Date:
2016-07-20 02:42:56 UTC
List:
ruby-core #76463
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 <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>