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

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

[Dan0042 (Daniel DeLorme) via ruby-core]

Issue #20884 has been reported by Dan0042 (Daniel DeLorme).

----------------------------------------
Feature #20884: reserve "Ruby" toplevel module for Ruby language
https://bugs.ruby-lang.org/issues/20884

* 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/

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

[ioquatix (Samuel Williams) via ruby-core]

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/
 ______________________________________________
 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/

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

[hsbt (Hiroshi SHIBATA) via ruby-core]

Issue #20884 has been updated by hsbt (Hiroshi SHIBATA).


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

----------------------------------------
Feature #20884: reserve "Ruby" toplevel module for Ruby language
https://bugs.ruby-lang.org/issues/20884#change-110575

* 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/

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

[Eregon (Benoit Daloze) via ruby-core]

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/

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

[Dan0042 (Daniel DeLorme) via ruby-core]

Issue #20884 has been updated by Dan0042 (Daniel DeLorme).

Description updated

Eregon (Benoit Daloze) wrote in #note-3:
> I'd suggest to update the description to use `Ruby::VERSION`).

Ok, did that.

----------------------------------------
Feature #20884: reserve "Ruby" toplevel module for Ruby language
https://bugs.ruby-lang.org/issues/20884#change-110598

* 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/

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

[matz (Yukihiro Matsumoto) via ruby-core]

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/
 ______________________________________________
 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/

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

[mame (Yusuke Endoh) via ruby-core]

Issue #20884 has been updated by mame (Yusuke Endoh).


Discussed at the dev meeting.

@matz 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 to `Ruby::`.
* 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`.

----------------------------------------
Feature #20884: reserve "Ruby" toplevel module for Ruby language
https://bugs.ruby-lang.org/issues/20884#change-110976

* 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/

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

[st0012 (Stan Lo) via ruby-core]

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:

![](Screenshot%202024-12-25%20at%2012.00.39.png)


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/
 ______________________________________________
 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/