From: shugo@ruby-lang.org
To: ruby-core@ruby-lang.org
Subject: [ruby-core:77227] [Ruby trunk Feature#12086] using: option for instance_eval etc.
Date: Fri, 09 Sep 2016 03:08:44 +0000 [thread overview]
Message-ID: <redmine.journal-60454.20160909030844.38761a876022a8d2@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-12086.20160219073402@ruby-lang.org
Issue #12086 has been updated by Shugo Maeda.
Charles Nutter wrote:
> > Yes, you'll get unexpected results in this case.
>
> I think you'd get unexpected results in my original case too, wouldn't you? Both of those two blocks still have the same prev_cref, which is where the refinements collection comes from. Am I wrong?
Ah, I was wrong...in both cases you get *expected* results because cref is newly created by each call of instance_eval(using:).
I tried the following code, and Thread X always returned "refined by X" and Thread Y always returned "Y".
```ruby
module X; refine Fixnum do; def +(x); "refined by X"; end; end; end
module Y; refine Fixnum do; def +(y); "refined by Y"; end; end; end
def eval_with_my_refinements(refinements, &block)
instance_eval(using: refinements, &block)
end
b = Proc.new { 100.times { p [Thread.current.name, 1 + 1]; Thread.pass } }
[
Thread.new { Thread.current.name = "X"; eval_with_my_refinements(X, &b) },
Thread.new { Thread.current.name = "Y"; eval_with_my_refinements(Y, &b) },
].each(&:join)
```
> > It's true that cache is invalidated by instance_eval(using:), but global method caching has been improved in MRI, and I don't know how different compared to JRuby.
>
> What is the impact of that invalidation? I am not familiar with how MRI globally invalidates these days and how it reduces the impact.
In MRI, global cache is invalidated per class.
> > I don't know it should be applied to code used with the new features.
>
> But if I have chosen not to use this feature, for the performance of my application, I'll also have to check every library I depend on to see if they use the feature. If I don't, such a library might impact the performance of my entire application. I don't think we want that.
>
> So summarizing my concerns up to this point:
>
> * The current design is not thread-safe. It might be possible to make it thread-safe at the cost of additional complexity, which may mean further reducing performance. (design issue)
> * If any code in the system uses the current implementation of this feature, that impacts the performance unrelated code by invalidating global caches. (implementation issue)
> * All blocks everywhere in the system will now be suspect; you will not be able to tell what method will be called unless you control everywhere that block will be passed (usability issue, in my opinion)
Anyway, I understand your concerns. Thanks for your feedback.
----------------------------------------
Feature #12086: using: option for instance_eval etc.
https://bugs.ruby-lang.org/issues/12086#change-60454
* 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/
next prev parent reply other threads:[~2016-09-09 2:36 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <redmine.issue-12086.20160219073402@ruby-lang.org>
2016-02-19 7:34 ` [ruby-core:73886] [Ruby trunk Bug#12086] using: option for instance_eval etc shugo
2016-02-19 10:01 ` [ruby-core:73887] [Ruby trunk Feature#12086] " shugo
2016-06-13 7:27 ` [ruby-core:75972] " nobu
2016-06-13 7:31 ` [ruby-core:75975] " matz
2016-07-08 7:56 ` [ruby-core:76316] " shugo
2016-07-08 8:02 ` [ruby-core:76317] " shugo
2016-07-08 12:58 ` [ruby-core:76320] " nobu
2016-07-09 0:17 ` [ruby-core:76326] " shugo
2016-07-20 2:42 ` [ruby-core:76463] " shyouhei
2016-09-07 8:10 ` [ruby-core:77196] " tom.enebo
2016-09-07 12:43 ` [ruby-core:77208] " headius
2016-09-07 13:59 ` [ruby-core:77209] " headius
2016-09-07 14:08 ` [ruby-core:77211] " headius
2016-09-07 14:22 ` [ruby-core:77212] " headius
2016-09-08 23:27 ` [ruby-core:77223] " shugo
2016-09-08 23:36 ` [ruby-core:77224] " shugo
2016-09-08 23:40 ` [ruby-core:77225] " shugo
2016-09-09 1:20 ` [ruby-core:77226] " headius
2016-09-09 3:08 ` shugo [this message]
2019-12-29 19:46 ` [ruby-core:96583] [Ruby master " eregontp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-60454.20160909030844.38761a876022a8d2@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).