[ruby-core:119891] [Ruby master Feature#20884] reserve "Ruby" toplevel module for Ruby language
From:
"Eregon (Benoit Daloze) via ruby-core" <ruby-core@...>
Date:
2024-11-12 10:53:28 UTC
List:
ruby-core #119891
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 -- [email protected]
To unsubscribe send an email to [email protected]
ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/
