From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 95B881F4C0 for ; Tue, 15 Oct 2019 15:16:15 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 7E61E120A09; Wed, 16 Oct 2019 00:16:06 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 2AAC212091F for ; Wed, 16 Oct 2019 00:16:02 +0900 (JST) Received: by filter0155p3mdw1.sendgrid.net with SMTP id filter0155p3mdw1-31825-5DA5E2B5-177 2019-10-15 15:16:05.99232651 +0000 UTC m=+333950.654267048 Received: from herokuapp.com (unknown [52.91.31.13]) by ismtpd0043p1mdw1.sendgrid.net (SG) with ESMTP id NlDx7jKbTf6K7S9Cnq0KLA for ; Tue, 15 Oct 2019 15:16:05.893 +0000 (UTC) Date: Tue, 15 Oct 2019 15:16:06 +0000 (UTC) From: merch-redmine@jeremyevans.net Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 70925 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16157 X-Redmine-Issue-Author: Dan0042 X-Redmine-Sender: jeremyevans0 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: =?us-ascii?Q?RVE3t853K5scBhbmJHUzZTFFeVC=2FZSUmHZ0Dc+26wcEi2CTgsF1oz0wTSSxGGN?= =?us-ascii?Q?BI5BV4+5ZAK5MBBB+VTrfUJzaVkLIrzG+PdKRFd?= =?us-ascii?Q?AhlO4BqtPZuS=2Fbc64NMX8LhG4pokg1vN9d1Ck2N?= =?us-ascii?Q?PkH30Bj9yJrXBgy+xzqZseLv4NmvCh6ZdHRk6Lm?= =?us-ascii?Q?yedA3be6mjYgqvM+ULPoyewBOYeDaV9=2FiiA=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95337 Subject: [ruby-core:95337] [Ruby master Misc#16157] What is the correct and *portable* way to do generic delegation? 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 #16157 has been updated by jeremyevans0 (Jeremy Evans). Eregon (Benoit Daloze) wrote: > @jeremyevans0 That is not future proof and will break as soon as `ruby2_keywords` is removed. I did say: `That will work in all ruby versions until ruby2_keywords is removed`. > I don't think we want to keep using `ruby2_keywords` forever, i.e., does it make sense to use `ruby2_keywords` in Ruby 4? It certainly could. I believe the idea of removing it after Ruby 2.6 is EOL is that gems that work on supported Ruby versions could continue to have a single method definition. That method definition may need to change if `ruby2_keywords` is removed, though. > From the name and my understanding of it, `ruby2_keywords` should only be used in 2.7 for transition, 3.0 later should explicitly pass kwargs. The idea behind `ruby2_keywords` is to be able to use a single method definition for delegation methods, that will work for older ruby versions (where `ruby2_keywords` is not defined and won't be called), and also newer versions (where `ruby2_keywords` is defined and will be called). It is designed to require the fewest possible changes to existing code in order to get it to work in Ruby 2.7 without warnings and in Ruby 3.0 without errors. > I think using `ruby2_keywords` is also really not pretty, so I hope once 2.x support is dropped libraries will not use the `ruby2_keywords` workaround for delegation anymore. > > So I believe this is the currently complete and future-proof way to do delegation that works on Ruby 2.x - 3.0+: > > ```ruby > class Proxy < BasicObject > def initialize(target) > @target = target > end > > if RUBY_VERSION >= "3.0" > def method_missing(*args, **kwargs, &block) > @target.send(*args, **kwargs, &block) > end > else > def method_missing(*args, &block) > @target.send(*args, &block) > end > ruby2_keywords :method_missing if respond_to?(:ruby2_keywords, true) # For 2.7 > end > end > ``` If you have an existing method: ```ruby def method_missing(*args, &block) @target.send(*args, &block) end ``` The idea with `ruby2_keywords` is that can currently just add a line so it works in 2.7+: ```ruby def method_missing(*args, &block) @target.send(*args, &block) end ruby2_keywords :method_missing if respond_to?(:ruby2_keywords, true) ``` If at some point we do remove `ruby2_keywords`, you could then switch it to: ```ruby def method_missing(*args, **kwargs, &block) @target.send(*args, **kwargs, &block) end ``` The assumption is by that point, the code will no longer need to support Ruby <2.7. So at no point does the code need two method definitions to work with all supported Ruby versions. > At the end of my comment in https://bugs.ruby-lang.org/issues/16188#note-5 I discussed why I believe `ruby2_keywords` is a non-trivial cost on performance, and so should be IMHO only in Ruby 2.7. I'll try to respond to that today, but it is quite long. > I also propose there an explicit way to mark call sites converting the Hash flagged by `ruby2_keywords` to keywords again with `send_keyword_hash`. CRuby's C-API supports this. It's not difficult to implement such a method. However, this explicit approach requires more changes to existing code, which is sort of the opposite goal of `ruby2_keywords`. > That I think would make it easier to understand by being less magic and limit the performance cost to only where it's needed. It's more explicit at the call site where the conversion of hash to keywords takes place. I'm not sure it is any easier to understand for the typical Ruby programmer. It also requires modifying the method definition. The point of `ruby2_keywords` is you do not have to modify an existing method definition, you can just add `ruby2_keywords :method_name if respond_to?(:ruby2_keywords, true)` after the method definition, and things will continue to work as they did before. ---------------------------------------- Misc #16157: What is the correct and *portable* way to do generic delegation? https://bugs.ruby-lang.org/issues/16157#change-82045 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal * Assignee: ---------------------------------------- With the keyword argument changes in 2.7 we must now specify keyword arguments explicitly when doing generic delegation. But this change is not compatible with 2.6, where it adds an empty hash to the argument list of methods that do not need/accept keyword arguments. To illustrate the problem: ```ruby class ProxyWithoutKW < BasicObject def initialize(target) @target = target end def method_missing(*a, &b) @target.send(*a, &b) end end class ProxyWithKW < BasicObject def initialize(target) @target = target end def method_missing(*a, **o, &b) @target.send(*a, **o, &b) end end class Test def args(*a) a end def arg(a) a end def opts(**o) o end end # 2.6 2.7 3.0 ProxyWithoutKW.new(Test.new).args(42) # [42] [42] [42] ok ProxyWithoutKW.new(Test.new).arg(42) # 42 42 42 ok ProxyWithoutKW.new(Test.new).opts(k: 42) # {:k=>42} {:k=>42} +warn [{:k=>42}] incompatible with >= 2.7 ProxyWithKW.new(Test.new).args(42) # [42, {}] [42] [42] incompatible with <= 2.6 ProxyWithKW.new(Test.new).arg(42) # error 42 42 incompatible with <= 2.6 ProxyWithKW.new(Test.new).opts(k: 42) # {:k=>42} {:k=>42} +warn {:k=>42} must ignore warning? cannot use pass_positional_hash in 2.6 ``` I don't know how to solve this, so I'm asking for the **official** correct way to write portable delegation code. And by **portable** I mean code that can be used in gems that target ruby 2.6 and above. -- https://bugs.ruby-lang.org/