[ruby-core:112907] [Ruby master Feature#19520] Support for `Module.new(name)` and `Class.new(superclass, name)`.
From:
"fxn (Xavier Noria) via ruby-core" <ruby-core@...>
Date:
2023-03-15 23:30:44 UTC
List:
ruby-core #112907
Issue #19520 has been updated by fxn (Xavier Noria).
> I don't think it's uncommon to cache instances of a class in some global mapping. Does Zeitwerk reload the entire namespace or just ones that changed? I don't know enough about it. @fxn (Xavier Noria) any thoughts on how this is handled?
Storing a class or module object whose constant is reloadable in a non-reloadable place is considered to be an error in Zeitwerk-based projects. You should not do that, period. It is not an error in the sense that you get an exception, but it is a logical error and we do not need to waste time thinking about such scenario. Users are not supposed to do this, and if they do, the consequences are out of scope, unsupported.
So, for example, let's say Foo is a reloadable module, and you include Foo in some place that is not reloadable, like ActiveRecord::Base. That is wrong, you'll have a stale module object on reload that won't reflect edits to Foo. This is documented in (5) [here](https://github.com/fxn/zeitwerk#rules-of-thumb).
> I'm assuming Zeitwerk reloading can create orphaned constants (i.e. it's calling remove_const).
Not really, let me explain.
If Foo is a top-level constant without autoloaded constants below, it is remove_const'ed. Fine.
If Admin is a top-level constant and the module it stores acts as a namespace so that we have Admin::UsersController, and Admin::Payments, Zeitwerk removes all of the constants. That is, it removes `:UsersController` and `:Admin` from the module stored in `Admin`, and then removes `:Admin` from `Object`.
In theory if the constants are used correctly, removing `:Admin` would be enough because everything else would not be reachable and eventually GCed. But just in case a user has a stale object cached somewhere, I want to make sure that at least its constants are gone.
Zeitwerk puts constraints on what projects can do to make autoloading/reloading solvable.
----------------------------------------
Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`.
https://bugs.ruby-lang.org/issues/19520#change-102424
* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
----------------------------------------
See <https://bugs.ruby-lang.org/issues/19450> for previous discussion and motivation.
[This proposal](https://github.com/ruby/ruby/pull/7376) introduces the `name` parameter to `Class.new` and `Module.new`:
```ruby
Class.new(superclass, name)
Module.new(name)
```
As a slight change, we could use keyword arguments instead.
## Example usage
The current Ruby test suite has code which shows the usefulness of this new method:
```ruby
def labeled_module(name, &block)
Module.new do
singleton_class.class_eval {
define_method(:to_s) {name}
alias inspect to_s
alias name to_s
}
class_eval(&block) if block
end
end
module_function :labeled_module
def labeled_class(name, superclass = Object, &block)
Class.new(superclass) do
singleton_class.class_eval {
define_method(:to_s) {name}
alias inspect to_s
alias name to_s
}
class_eval(&block) if block
end
end
module_function :labeled_class
```
The updated code would look like this:
```ruby
def labeled_module(name, &block)
Module.new(name, &block)
end
def labeled_class(name, superclass = Object, &block)
Class.new(superclass, name, &block)
end
module_function :labeled_class
```
--
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/postorius/lists/ruby-core.ml.ruby-lang.org/