[ruby-core:119891] [Ruby master Feature#20884] reserve "Ruby" toplevel module for Ruby language

["Eregon (Benoit Daloze) via ruby-core" <ruby-core@ml.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/
 ______________________________________________
 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/