From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [94.130.110.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 738A71F4C1 for ; Tue, 12 Nov 2024 10:54:14 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=TfUBXrvv; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=dhhPO3CN; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1731408821; bh=EXGr2UCitgRXWjNgtul9KpthP20xfbXB5AUHhgwCx0s=; h=Date:References:To:Reply-To:Subject:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From:Cc:From; b=TfUBXrvvji5LJSykMz9ap4nrgU+islD0mS1uQ+7BZwtGxVbQUiiuvMZL4aRZQkW7D qG+l8egDLL3HU5Fipkji2C6QBAkwyAk6xqqX0LrS+AMdtLp2a4kKZBZLoHvfX7uw2Q urkA7S2xsnKiKOCrAA2J8Ag7imdS8cQlm6IFeZKQ= Received: from nue.mailmanlists.eu (localhost [IPv6:::1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 8C37444B73 for ; Tue, 12 Nov 2024 10:53:41 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=dhhPO3CN; dkim-atps=neutral Received: from s.wrqvwxzv.outbound-mail.sendgrid.net (s.wrqvwxzv.outbound-mail.sendgrid.net [149.72.154.232]) by nue.mailmanlists.eu (Postfix) with ESMTPS id 1B81D44B44 for ; Tue, 12 Nov 2024 10:53:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ruby-lang.org; h=from:references:subject:mime-version:content-type: content-transfer-encoding:list-id:to:cc:content-type:from:subject:to; s=s1; bh=34i+E84ZkisRNff6XR87ZlX9eUbRHzKChFJzKpPku+g=; b=dhhPO3CNTqhcknjri2AmS8I/zOBUr8rz6K3kSqaBI6oa3klKnEAzQVUUmcBXa6asA5dG DWu1+w5C1YVa0SsW75l9PypAq23oPyAuuL4/i2+MhI3BUX7IoZmZNoFH0KTi/ZNq3yLQ80 UIuExATi+9Ss5vcHV/OEo4kw+RhZq+dRoaI3BKZXdVLgR9LINhTWYtlgQK6bCTNs2WBsMr OQZZkwPg4xER2nrFQAeZFd2cQiJY/EDiHTesSJj0E5pKdoCXfrZjj/VMRFV1588nc2Inc8 cfOS0HwdLClnXgOEOwraKCBuX0eX+aWQoTaMAzoX/d7i/lSw8g+1ylOzklsvNh5w== Received: by recvd-d66cff667-86cnt with SMTP id recvd-d66cff667-86cnt-1-673333A8-2 2024-11-12 10:53:28.56801393 +0000 UTC m=+5244918.277930443 Received: from herokuapp.com (unknown) by geopod-ismtpd-24 (SG) with ESMTP id 4zI8N0GXSTK8N-A3rl4h7g for ; Tue, 12 Nov 2024 10:53:28.490 +0000 (UTC) Date: Tue, 12 Nov 2024 10:53:28 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 20884 X-Redmine-Issue-Author: Dan0042 X-Redmine-Issue-Priority: Normal X-Redmine-Sender: Eregon 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-Redmine-MailingListIntegration-Message-Ids: 96559 X-SG-EID: =?us-ascii?Q?u001=2EByjZWvxTCjdoV8K03xEuhE7KqN4thWULFLM7+oH78KY30oYB3qFthsDpL?= =?us-ascii?Q?4w4cbYa3ttBh8bAHPOnE=2FkzPba67JNu7Lnrked2?= =?us-ascii?Q?O7K9VQ=2FJax3FplBXuNCsV4pHEJO=2Fn5PZzuKUVLv?= =?us-ascii?Q?EQ8LT64+A9ZkHf6nBIQ56bw3HR+rMDJBAEePLaJ?= =?us-ascii?Q?aOoGM02GNZ4rvTTMpf1dKhFDAgVtZscZciNDSf7?= =?us-ascii?Q?VWLbUQcUJEBUNKZFu8Ibw0UxtWy0lHB8YObDeJ9?= =?us-ascii?Q?cf7lLFKgOkjZEeV=2FJYZui482sA=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: XFMOV3DGTWQ57P3PI7PMYRYR2VZFU6P5 X-Message-ID-Hash: XFMOV3DGTWQ57P3PI7PMYRYR2VZFU6P5 X-MailFrom: bounces+313651-b711-ruby-core=ml.ruby-lang.org@em5188.ruby-lang.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:119891] [Ruby master Feature#20884] reserve "Ruby" toplevel module for Ruby language List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "Eregon (Benoit Daloze) via ruby-core" Cc: "Eregon (Benoit Daloze)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #20884 has been updated by Eregon (Benoit Daloze). I think this is a great idea, and would allow to introduce some methods/constants/modules/classes we wouldn't be able to otherwise due to concerns of conflicting with existing constants. I think it would be a good place for: * a method returning the ruby executable, there is currently `RbConfig.ruby` and `Gem.ruby` but neither are the right place for it. * a method returning the main ruby script, `Process.argv0` is so confusing. * a method returning the original ruby interpreter options (#6648) * a method returning the original user-level arguments, i.e. the initial deeply-copied value of `ARGV` (#6648) * a method returning the original working directory, as a String, i.e. the initial value of `Dir.pwd` (#6648) * a class like SourceLocation/CodeLocation with `start_{line,column,offset}`, `end_{line,column,offset}` and `code/source` for https://bugs.ruby-lang.org/issues/6012#note-19 > Thread::Backtrace::Location would have made a lot of sense as Ruby::Backtrace::Location Agreed. > RubyVM is considered specific to CRuby; so RubyVM::AbstractSyntaxTree should be Ruby::AbstractSyntaxTree if it is meant to be present in other implementations. AbstractSyntaxTree is parse.y-specific and CRuby-specific, so that's not a good example. There is already Prism as the official and portable API to deal with Ruby ASTs. But indeed sometimes there were suggestions to add methods to RubyVM which are not CRuby-specific (e.g. `RubyVM.resolve_feature_path` in #15903), which is a problem as `RubyVM` can only exist on CRuby, as many gems rely on `defined?(RubyVM)` == CRuby or things like assuming `RubyVM::InstructionSequence` exists if `defined?(RubyVM)`. Adding it under `Ruby` makes it possible for other Ruby implementations to implement it, which is essential for any new functionality which can be implemented on other Ruby implementations. >>From a quick look at `RubyVM`, I think `keep_script_lines{,=}` should be moved, the rest does look truly CRuby-specific (specific JITs of CRuby, CRuby-specific bytecode, CRuby-specific VM options). Regarding `RUBY_*` constants I'm not sure there is much value to copy them under `Ruby` as backward-compatible code can't use them for a while, but I don't mind it either (they should stay uppercase though, I'd suggest to update the description to use `Ruby::VERSION`). ---------------------------------------- Feature #20884: reserve "Ruby" toplevel module for Ruby language https://bugs.ruby-lang.org/issues/20884#change-110582 * Author: Dan0042 (Daniel DeLorme) * Status: Open ---------------------------------------- `Ruby` would be a convenient namespace for many features of the Ruby language, in particular APIs related to the interpreter. All these constants: RUBY_VERSION RUBY_RELEASE_DATE RUBY_PLATFORM RUBY_PATCHLEVEL RUBY_REVISION RUBY_COPYRIGHT RUBY_ENGINE RUBY_ENGINE_VERSION RUBY_DESCRIPTION would have made a lot of sense as `Ruby::Version` etc. `Thread::Backtrace::Location` would have made a lot of sense as `Ruby::Backtrace::Location` `RubyVM` is considered specific to CRuby; so `RubyVM::AbstractSyntaxTree` should be `Ruby::AbstractSyntaxTree` if it is meant to be present in other implementations. In #6648 there's a bit of contention over where `ruby_args` should be. `RubyVM`, `RbConfig`, `Process` have all been proposed, but `Ruby` would be an excellent choice. `Process.argv0` was added in Ruby 2.1 but the `Process` namespace is really about OS-level process control (fork, signals, euid, limits) while this argv0 is not (in `ps` it's neither value of COMMAND nor CMD) so it would have made sense as `Ruby.argv0` The "ruby" gem name is reserved, so there's no conflict. https://rubygems.org/gems/ruby All in all, "Ruby" is an appropriate namespace for many Ruby things. We don't want to break compatibility over this, but we could at least start small by reserving the namespace, and see how it grows from there. module Ruby Version = ::RUBY_VERSION end -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/