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=-4.1 required=3.0 tests=BAYES_00,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 BE4E21F462 for ; Thu, 6 Jun 2019 09:59:09 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 14BBF120B63; Thu, 6 Jun 2019 18:59:05 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id 18177120ABA for ; Thu, 6 Jun 2019 18:59:02 +0900 (JST) Received: by filter0077p3mdw1.sendgrid.net with SMTP id filter0077p3mdw1-22933-5CF8E3E8-27 2019-06-06 09:59:04.749560158 +0000 UTC m=+147093.363929292 Received: from herokuapp.com (unknown [34.235.149.35]) by ismtpd0004p1iad2.sendgrid.net (SG) with ESMTP id v_3GuGFpQFOKP5xXAhvXpQ for ; Thu, 06 Jun 2019 09:59:04.717 +0000 (UTC) Date: Thu, 06 Jun 2019 09:59:04 +0000 (UTC) From: mame@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 68484 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15903 X-Redmine-Issue-Author: Eregon X-Redmine-Issue-Assignee: matz X-Redmine-Sender: mame 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?EJh2gqwnyqXtd++xo=2FinyA1V0bXouTB4FkWnzNiKb4=2F0sBuTncBtOJhEK5CJJw?= =?us-ascii?Q?1n4FQ55vVMxptr+PYRevMrtnoAu+HaniTtcI8mX?= =?us-ascii?Q?s8xQhdHcCoAebgKahc=2FGbySoHmkmMiOcg=2FU9RQ4?= =?us-ascii?Q?utlQHQ5+fyia0wD=2F5IG8ZKTnqgEqG4VopIAlb7g?= =?us-ascii?Q?AEP4oYEHcCIpq6FaNRPDyxCpMCXmSXZp+MQ=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 93007 Subject: [ruby-core:93007] [Ruby trunk Feature#15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path 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 #15903 has been updated by mame (Yusuke Endoh). Eregon (Benoit Daloze) wrote: > mame (Yusuke Endoh) wrote: > > However, we can't be too careful to add anything to `Kernel` nowadays. > > I propose only as a class method, not an instance method Oh sorry I missed the point. Fair enough. I'll ask matz's opinion at the next meeting. > > At least, I don't want to do that until we receive an actual request to make the method available in production. > > We very rarely receive this, e.g., even for RubyVM::InstructionSequence which is now used in production (bootsnap). > I think it is not a good criteria, it's just too easy to use `RubyVM` in user code. Let's try to remove it and see how many people are killed. (Joke) ---------------------------------------- Feature #15903: Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path https://bugs.ruby-lang.org/issues/15903#change-78383 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) * Target version: 2.7 ---------------------------------------- RubyVM contains mostly MRI-specific features but `resolve_feature_path` is clearly not MRI-specific. So I propose to move it as a class method of `Kernel`. I think this makes sense given the related `load` and `require` are defined in `Kernel` too. Moreover, moving this method outside `RubyVM` is *necessary* for other Ruby implementations to implement it, and keep the clean separation that `RubyVM` is only defined on MRI (see #15752). So, can I move `RubyVM.resolve_feature_path` to `Kernel.resolve_feature_path`? Do we need to keep the method on RubyVM (and deprecate it), or can we just remove it since anyway API under RubyVM is not stable? cc @mame -- https://bugs.ruby-lang.org/