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 1A23B1A601F4 for ; Fri, 8 Jul 2016 16:27:54 +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 23D20B5D860 for ; Fri, 8 Jul 2016 17:02:19 +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 9CA1118CC7B1 for ; Fri, 8 Jul 2016 17:02:19 +0900 (JST) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 14A701204B8; Fri, 8 Jul 2016 17:02:19 +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 C8258120464 for ; Fri, 8 Jul 2016 17:02:16 +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=OoYqbTsv2Og6Noy4vC6wGJAxf6Q=; b=jQ8iZwE0B8dxRpeb0W s3Bnz2X4/qWgLPjG7WIPwFSOfTNmU3gLg+6A6NgFykg//HTgTyTfOi5VJExUp7w2 p+IX2Cbh3srwujzOkA6Vy4q+LPp4PxFk3umrR7iBN/j59Lmxv61ncOHkyCPtDO6i VZ3M3fiq0XeekBbcT04BEZEpI= Received: by filter0435p1mdw1.sendgrid.net with SMTP id filter0435p1mdw1.4202.577F5DFF25 2016-07-08 08:02:07.600333696 +0000 UTC Received: from herokuapp.com (ec2-54-234-215-148.compute-1.amazonaws.com [54.234.215.148]) by ismtpd0006p1iad1.sendgrid.net (SG) with ESMTP id QM8rwHmjTHSq90UEt6PVKw for ; Fri, 08 Jul 2016 08:02:07.385 +0000 (UTC) Date: Fri, 08 Jul 2016 08:02:07 +0000 From: shugo@ruby-lang.org To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 51072 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS5pYrQVmMe8FAyN2xKJVoCHWzMzDN6cpV0HTv 8BPXITsVd3hKsKQhjP1aGu8J+LDeLm8c5Jdati9C1dfQB8DSOp2OzV8sRkR3BKtTLUplIEbttkdkOp jVGzf4rwt1+U/ohuzerS/etHP+MKiBrZfEmy36yvpWbtsa3sEhet2J2mTQ== X-ML-Name: ruby-core X-Mail-Count: 76317 Subject: [ruby-core:76317] [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. Yukihiro Matsumoto wrote: > I like the idea, but I understand this makes implementation harder (especially for performance). Speaking of performance, inline cache cannot store refined methods because the same block can be executed with different refinements with this feature. However, there is no performance degradation for code without refinements. ---------------------------------------- Feature #12086: using: option for instance_eval etc. https://bugs.ruby-lang.org/issues/12086#change-59553 * 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/