Issue #20884 has been updated by ioquatix (Samuel Williams). +1. However, if we introduce it, can we also introduce a document to guide the evolution, e.g. naming conventions, in scope and out of scope usage, etc. I suppose I'd expect constants to be upper case still, e.g. `Ruby::VERSION`. ---------------------------------------- Feature #20884: reserve "Ruby" toplevel module for Ruby language https://bugs.ruby-lang.org/issues/20884#change-110574 * 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/

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/

Issue #20884 has been updated by matz (Yukihiro Matsumoto). It's OK for me to reserve `Ruby` constant (module) for the future. It should only contain portable information among implementations. Matz. ---------------------------------------- Feature #20884: reserve "Ruby" toplevel module for Ruby language https://bugs.ruby-lang.org/issues/20884#change-110959 * 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/

Issue #20884 has been updated by st0012 (Stan Lo). File Screenshot 2024-12-25 at 12.00.39.png added This change introduced an unexpected side-effect to the [master documentation](https://docs.ruby-lang.org/en/master/index.html) as now all mentions of `Ruby` are linked to this new constant:  I think this should be addressed on the RDoc side so I opened https://github.com/ruby/rdoc/issues/1254 for it. ---------------------------------------- Feature #20884: reserve "Ruby" toplevel module for Ruby language https://bugs.ruby-lang.org/issues/20884#change-111184 * Author: Dan0042 (Daniel DeLorme) * Status: Closed ---------------------------------------- `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 ---Files-------------------------------- Screenshot 2024-12-25 at 12.00.39.png (499 KB) -- https://bugs.ruby-lang.org/