From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (kankan.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id CE6B41AE0027 for ; Fri, 9 Sep 2016 11:36:31 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id B9256B5D8FC for ; Fri, 9 Sep 2016 12:09:02 +0900 (JST) Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id 2963018CC80D for ; Fri, 9 Sep 2016 12:09:02 +0900 (JST) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id EE350120493; Fri, 9 Sep 2016 12:08:57 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from o2.heroku.sendgrid.net (o2.heroku.sendgrid.net [67.228.50.55]) by neon.ruby-lang.org (Postfix) with ESMTPS id 45020120459 for ; Fri, 9 Sep 2016 12:08:51 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.me; h=from:to:references:subject:mime-version:content-type:content-transfer-encoding:list-id; s=smtpapi; bh=OiEmK+qnEJZ8W3keHXMpqHBiNO0=; b=riklhWUhTr7YzwyWn0 6p6zhDtJ6Bv9RBmX/nNDOpfdoI8fQ7N/IhKmnqu0gL3/T+P+NzxUHWl3+Qr1DE2A KrQMjwftp18Bsm47s9bwuOe7lzUlgqb5yv5BSxMlJPNmDCN03ne+S2N0tHV+93t+ jvy0wMz9Y+XVi8MGkBMWDhodU= Received: by filter0993p1mdw1.sendgrid.net with SMTP id filter0993p1mdw1.10052.57D227BC2E 2016-09-09 03:08:44.734633536 +0000 UTC Received: from herokuapp.com (ec2-54-163-214-37.compute-1.amazonaws.com [54.163.214.37]) by ismtpd0002p1iad1.sendgrid.net (SG) with ESMTP id Y3GUNAsIRIqMrHlhQTkkRg Fri, 09 Sep 2016 03:08:44.710 +0000 (UTC) Date: Fri, 09 Sep 2016 03:08:44 +0000 From: shugo@ruby-lang.org To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 52025 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 12086 X-Redmine-Issue-Author: shugo X-Redmine-Sender: shugo X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS6/EP8/DC9HXSgdGzwn4lRtqQ/7LlbDwjBX7s FeFVH149AbGUZN4/j6jKbe8GP4ubw11HwziQbRi/DrsYo7cADml37Wv/WmPK04QAf85XriInZj989E nxxQPUehtYGNMvc1U12L7PgQZca1ofuWXJ9bJMLhJwkG/XIQYpMUOOtNJQ== X-SendGrid-Contentd-ID: {"test_id":"1473390525"} X-ML-Name: ruby-core X-Mail-Count: 77227 Subject: [ruby-core:77227] [Ruby trunk Feature#12086] using: option for instance_eval etc. X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" 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 . 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/