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 (smtp.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id 6BD111AE022E for ; Wed, 7 Sep 2016 22:27:45 +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 51D2DB5D986 for ; Wed, 7 Sep 2016 23:00:18 +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 27E2118D1D0D for ; Wed, 7 Sep 2016 23:00:19 +0900 (JST) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 4C19B1204DE; Wed, 7 Sep 2016 23:00:16 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from o10.shared.sendgrid.net (o10.shared.sendgrid.net [173.193.132.135]) by neon.ruby-lang.org (Postfix) with ESMTPS id 9DA9C120495 for ; Wed, 7 Sep 2016 23:00:12 +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=K6uNhUCW2SLJun9TNuJmx/4tgRA=; b=LtKJU/70GrQsFp5S1Y xFBomt/VOsaBJfmam9Enr0BHKTy0K7ROUKY44T9wBkM/mMBIS4LmAqxw/hfb++CZ 3KplVc0qLqR0iD0INcJaG+2uZ225Bo8cMb6WxuhWGCsIOcCEkX+o9NGkpkY/FlQh RiijPugvBZkYYXjkCNfKiWsyw= Received: by filter0554p1mdw1.sendgrid.net with SMTP id filter0554p1mdw1.22517.57D01D5A53 2016-09-07 13:59:54.675934163 +0000 UTC Received: from herokuapp.com (ec2-54-204-80-184.compute-1.amazonaws.com [54.204.80.184]) by ismtpd0001p1iad1.sendgrid.net (SG) with ESMTP id RGLxHBa2Q8iPZCst2SgHvA Wed, 07 Sep 2016 13:59:54.644 +0000 (UTC) Date: Wed, 07 Sep 2016 13:59:54 +0000 From: headius@headius.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 52004 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 12086 X-Redmine-Issue-Author: shugo X-Redmine-Sender: headius 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS6YvNdexr6lE5qaLUsq+7axwoNcQoJV4ghGJG 39vzQtCYLxzo0W0U7M9yiki23tHE+vBkhDDR9FMIyXshewmlPE4spkGkHM7dLIpC+D8UJ0Z9Wt0ghd 6rcsn2NT8+ohegzQ2+FxjG0duNp0YeyFxxtRCbcbl5F1NNbR24231VMmlw== X-ML-Name: ruby-core X-Mail-Count: 77209 Subject: [ruby-core:77209] [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 Charles Nutter. Is this thread-safe? Would it be possible for two threads to refine the same block in different ways and step on each other? I see that instance_eval (yield_under) creates a new cref for each instance_eval call...but if I'm reading it right it shares the refinements collection with prev_cref, right? So it seems to me a given block could have its refinements change across threads. rb_using_module impacts the method cache. Not sure if that's a concern or not, but one thread doing dynamic refinements could impact *every* unrefined call on other threads, right? Cross-thread refinement changes could impact work MRI folks are doing on optimization and deoptimization. I have other questions to understand how MRI reduces the impact of refinements on unrefined code... Does MRI throw away the block's method cache every time instance_eval is called? Method caches can be se per-activation, rather than just sourced from the iseq? Does MRI currently check for refinements before every method call? ---------------------------------------- Feature #12086: using: option for instance_eval etc. https://bugs.ruby-lang.org/issues/12086#change-60424 * 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/