Feature #20884
openreserve "Ruby" toplevel module for Ruby language
Description
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
Updated by ioquatix (Samuel Williams) about 1 month ago
+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
.
Updated by hsbt (Hiroshi SHIBATA) about 1 month ago
I prefer this proposal.
The "ruby" gem name is reserved, so there's no conflict. https://rubygems.org/gems/ruby
FYI: I'm an owner of ruby
gem.
I suppose I'd expect constants to be upper case still, e.g. Ruby::VERSION.
+1
Updated by Eregon (Benoit Daloze) about 1 month ago ยท Edited
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
andGem.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}
andcode/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{,=}
could/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
).
Updated by Dan0042 (Daniel DeLorme) about 1 month ago
- Description updated (diff)
Updated by Dan0042 (Daniel DeLorme) about 1 month ago
- Description updated (diff)
Eregon (Benoit Daloze) wrote in #note-3:
I'd suggest to update the description to use
Ruby::VERSION
).
Ok, did that.
Updated by matz (Yukihiro Matsumoto) 2 days ago
It's OK for me to reserve Ruby
constant (module) for the future. It should only contain portable information among implementations.
Matz.
Updated by nobu (Nobuyoshi Nakada) 1 day ago
- Status changed from Open to Closed
Applied in changeset git|4d86f3bf6d1fe7bf7d4b25fc42f7aba9f401bbb4.
[Feature #20884] Reserve "Ruby" toplevel name
Updated by nobu (Nobuyoshi Nakada) 1 day ago
- Status changed from Open to Closed
Applied in changeset git|197a3efc751f43956fc9ad30d688b4bfa3f7fbdb.
[Feature #20884] News of toplevel "Ruby" name reservation
Updated by mame (Yusuke Endoh) 1 day ago
Discussed at the dev meeting.
@matz (Yukihiro Matsumoto) decided that Ruby 3.4 warns when ::Ruby is defined.
$ ./miniruby -we 'Ruby = 1'
-e:1: warning: ::Ruby is reserved for Ruby 3.5
If there are no major problems, it is likely that module Ruby
will be predefined in Ruby 3.5.
However, note that what to put in the ::Ruby
module requires futher discussion.
-
Ruby::Backtrace::Location
was opposed by nobu. -
AbstractSyntaxTree
is in RubyVM to make it explicitly implementation-dependent, so it will not be moved toRuby::
. - No one sympathized with
Ruby.argv0
in the dev meeting.Process.argv0
is good enough. - #6648 is not agreed at the specification level, and I think it is unlikely to be a class method in
::Ruby
.