Issue #19520 has been updated by ufuk (Ufuk Kayserilioglu). I am in complete agreement with @Eregon and I would also be against `Class#name` and `Module#name` method behaviour changing in this way. I am one of the maintainers of the Tapioca gem, which, among other things, does a lot of runtime introspection to discover constants, methods, mixins defined by gem so that it can generate interface files for them (RBI files for today). Currently, the only protection that we have for finding the real name of a constant is the ability to rebind the `Module#name` method to the constant in question. If the result is `nil`, then the constant is anonymous, otherwise we are guaranteed that the name maps to the constant (since we reach the constant via "a" name in the first place). Given that context, if `Module#name` starts returning any arbitrary string that does not in any form map to the actual name of the constant, there is no alternative method that Tapioca can use to get that information. Having said all of this, I understand that there are some use-cases where it might be good to be able to display a more friendly name for a constant for the user (in this case, a developer as the user). I would argue that we don't have to mess with the `name` method to get that benefit. The use-case presented can equally be achieved by adding something like a `Module#display_name` method (and even a setter for it) which `to_s` and `inspect` could use when `name` is `nil`. In my opinion, doing so would achieve what the use-case is trying to do, without changing any existing behaviour. ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-102297 * 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/

Issue #19520 has been updated by Eregon (Benoit Daloze). ioquatix (Samuel Williams) wrote in #note-6:

@ufuk It's already the case that it's trivial to override `Class#name` and have it return something other than a constant.

As @ufuk said in his comment, he uses `Module.instance_method(:name).bind_call(mod)`, and that's unaffected by `def c.name` but it would be by this new feature. ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-102303 * 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/

Issue #19520 has been updated by ioquatix (Samuel Williams).

Usage in tests is not convincing to me, one could just assign those to e.g. Testing::Foo or so.

Your suggestion doesn't work well in practice, e.g. https://github.com/rspec/rspec-core/blob/d722da4a175f0347e4be1ba16c0eb763de4...

uses `Module.instance_method(:name).bind_call(mod)`, and that's unaffected by `def c.name` but it would be by this new feature.

This already appears broken to me: ```ruby m = Module.new => #<Module:0x00007f4ea0f5d160> m.class_eval("class Bar;end") bar = m::Bar => #<Module:0x00007f4ea0f5d160>::Bar Module.instance_method(:name).bind_call(bar) => "#<Module:0x00007f4ea0f5d160>::Bar" ``` The name given here is not valid. One way to resolve the above issue is to expose when a name is a valid permanent global name, or when it's a temporary anonymous name. e.g. `m.anonymous?` at least allows you to rule out types which are not expected to be resolved. Unfortunately as I already demonstrated, even permanent global names can be fake/resolvable and it is trivial to construct such a case, so `!m.anonymous?` does not mean that `eval(m.name)` will result in anything useful. ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-102312 * 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/

Issue #19520 has been updated by ufuk (Ufuk Kayserilioglu). ioquatix (Samuel Williams) wrote in #note-6:

The problem is Ruby does not use this internally ... Adding a display name might work, but it's the same problem as outlined above.

Yes, that has the same problem, but my suggestion was to make `to_s` and `inspect` respect the value of `display_name` if it was set, so that it would not have the same problem outlined above. I still don't understand why we would want to risk breaking so many assumptions existing code has already made about how constants and constant names work (regardless of the soundness of it) to add a feature that is a nice-to-have. Especially when there is a backward-compatible way to provide such a feature that is being suggested. ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-102316 * 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/

Issue #19520 has been updated by Eregon (Benoit Daloze). ioquatix (Samuel Williams) wrote in #note-12:

I don't understand this argument at all. The assumptions are already broken by the trivial examples already given.

They are not or very rarely broken in practice, that matters a lot.

=> "#<Module:0x00007f4ea0f5d160>::Bar" The name given here is not valid.

That's fine, this is easy to recognize there an anonymous module in there, there is no confusion. Unlike a `Foo::Bar` name with this feature and yet never having a `Foo` constant defined on Object. ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-102357 * 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/

Issue #19520 has been updated by ioquatix (Samuel Williams).

there won't be a way to ever get the actual name of that module, regardless of it was anonymous or named. It would forever return the name that the user specified.

That's not how the proposal here works. One you assign a permanent name, it replaces any fake/temporary name. ```ruby m = Module.new("fake") => fake m.name => "fake" M = m => M m.name => "M" Module.instance_method(:name).bind_call(m) => "M" ```

That's fine, this is easy to recognize there an anonymous module in there, there is no confusion. Unlike a Foo::Bar name with this feature and yet never having a Foo constant defined on Object.

Don't live code reloading systems work exactly like this, creating a whole bunch of "orphaned" constants? ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-102364 * 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/

Issue #19520 has been updated by Eregon (Benoit Daloze). I had a call with @ioquatix, trying to explain the importance of the name that Ruby shows us, for example: `undefined method 'zzz' for #<Foo::Bar:0x00007efc38711fc0> (NoMethodError)` people will of course expect that `Foo::Bar` refers to the class of the object. For instance maybe they want to create a new instance of Foo::Bar, so writing Foo::Bar in the code must refer to that class. Yes, it's possible to break it with remove_const/const_set, but in practice this almost never happens, and if it does I would consider it a very serious bug of whatever uses remove_const/const_set to break it. And the same for Zeitwerk, while I guess it's possible to break the constant path<->module mapping there with reloading e.g. maybe by storing an old Class in a global variable and doing that only once per process (e.g. only if the global is unset), it's just extremely uncommon. I don't think Rails users get this problem often at all (e.g. we'd see more issues on rails or zeitwerk if they did). One thing that could help is for this name to be visually different than a regular constant path, so e.g. it cannot start with an uppercase letter (as said in https://bugs.ruby-lang.org/issues/19450#note-17), and probably start with some symbol to make it even more obvious. (Actually C code can define lowercase constants, so just not uppercase first letter is not enough, e.g. `IO::generic_writable` seen from `StringIO.ancestors`).

One you assign a permanent name, it replaces any fake/temporary name.

That wasn't clear to me and the description doesn't seem to mention it. It means there is yet another state of naming for modules in addition to the existing fully-anonymous (`#<Module:0x0123>`), knows its own name but not its lexical parent/nesting (`#<Module:0x0123>::A`) and fully-named (`A::B`). So that's some extra complexity both for the user and for implementations. I thought the "fake name" would be considered fully-named. IIRC naming of constants under a module is only done if a module is fully-named, and I think that's the feature you want here. What I didn't have time to discuss on the call is what's the use-case for this besides tests which want to label anonymous modules/classes to make it easier to debug them. @ioquatix mentioned his own reloading logic, but I'm not sure how that works, e.g., how do you refer to another model if not all models have a fully-named constant path? ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-102396 * 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/

Issue #19520 has been updated by ioquatix (Samuel Williams).

I had a call with @ioquatix (Samuel Williams), trying to explain the importance of the name that Ruby shows us, for example: undefined method 'zzz' for #<Foo::Bar:0x00007efc38711fc0> (NoMethodError) people will of course expect that Foo::Bar refers to the class of the object.

As demonstrated, if users want to do this, it's already possible. ```ruby Foo = Module.new #=> Foo Foo.class_eval("class Bar;end") bar = Foo::Bar.new #=> #<Foo::Bar:0x000055c0ae3c1e68> Object.send(:remove_const, Foo.name) #=> Foo bar.zzz #=> undefined method `zzz' for #<Foo::Bar:0x000055c0ae3c1e68> (NoMethodError) Foo::Bar #=> uninitialized constant Foo (NameError) ```

(Actually C code can define lowercase constants, so just not uppercase first letter is not enough, e.g. IO::generic_writable seen from StringIO.ancestors).

It's not possible to access such constants using the normal constant lookup: ```ruby StringIO.ancestors #=> [StringIO, IO::generic_writable, IO::generic_readable, Enumerable, Data, Object, PP::ObjectMixin, Kernel, BasicObject] IO::generic_writable #=> undefined method `generic_writable' for IO:Class (NoMethodError) ``` But I also don't think that matters much for this proposal anyway.

"One you assign a permanent name, it replaces any fake/temporary name." -> That wasn't clear to me and the description doesn't seem to mention it. So that's some extra complexity both for the user and for implementations.

This is how Ruby already works internally, this is not part of my PR. This is how anonymous modules already work. https://github.com/ruby/ruby/blob/868f03cce1a2d7a4df9b03b8338e3af4c69041d0/i... is the implementation that already exists. This is a way to cache the class names. It is used to inform child modules that the class name won't change in the future. ```ruby m = Module.new # internally, the name is not permanent. M = m # now it becomes permanent and any child constants in m should update their names to be permanent too. ``` This is part of the reason why one could consider `remove_const` to be buggy.

And the same for Zeitwerk, while I guess it's possible to break the constant path<->module mapping there with reloading e.g. maybe by storing an old > Class in a global variable and doing that only once per process (e.g. only if the global is unset), it's just extremely uncommon.

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 any thoughts on how this is handled? I'm assuming Zeitwerk reloading can create orphaned constants (i.e. it's calling `remove_const`).

One thing that could help is for this name to be visually different than a regular constant path, so e.g. it cannot start with an uppercase letter > (as said in https://bugs.ruby-lang.org/issues/19450#note-17), and probably start with some symbol to make it even more obvious. (Actually C code can define lowercase constants, so just not uppercase first letter is not enough, e.g. IO::generic_writable seen from StringIO.ancestors).

This is the current convention for anonymous modules, to a certain extent. If one overrides `Class#name`, that's no longer true.

What I didn't have time to discuss on the call is what's the use-case for this besides tests which want to label anonymous modules/classes to make it easier to debug them.

Well, I think this is already explained multiple times, i.e. the examples I gave + Ruby's own CI.

Another thought: maybe a much simpler way to solve most of these use-cases is adding Module#source_location, which is the [file, line] at which the Module was created. That could also work for anonymous modules, they could capture at which file, line Module.new was called.

Do I think this is potentially a good idea? Yes. Does that work for all the example use cases I gave? No. I think what might make more sense is: - Introducing `anonymous?` as a predicate for whether a given class/module is itself rooted in the global namespace or not. - (Consider) changing `remove_const` to correctly convert class/module back to anonymous. ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-102399 * 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/

Issue #19520 has been updated by Eregon (Benoit Daloze).

As demonstrated, if users want to do this, it's already possible.

Yes, and it just doesn't matter much in practice because it almost never or never happens in real code. The point is if the name of a Module doesn't correspond to how to access it, then we simply cannot program in Ruby anymore because we can't use constant lookup anymore, e.g. we can't MyClass.new anymore, because the mapping of MyClass<->that Class instance is no longer as expected. Anything that breaks this expectation that every Rubyist relies on is a serious bug. Right now, bad usages of `remove_const`/`const_set` can do that, such bad usages should be fixed but OTOH as far as I see they are mostly from unrealistic cases. `Module.new("Fake")` would make this all too easy, and I would not be surprised many people would accidentally use it like that without realizing it breaks the expectations above significantly. So it's not that people would break these expectations on purpose, if they want to do that they can already do that (but nobody does). It's that this new API would let people think `Module.new("Fake")` is a good idea when it's a terrible terrible one (there is no constant `Fake` with that, or worse a constant `Fake` pointing to a different module).

This is how Ruby already works internally, this is not part of my PR. This is how anonymous modules already work.

That much I know. But nowhere in this description there is anything about a new state in between where the fake name is there but it can still be fully named after. I thought and I think everyone else reading that description thought that you would consider the "fake" name the final name for a Module.

If one overrides Class#name, that's no longer true.

Incorrect, as already said before, one cannot change the original Module#name, and exception messages from Ruby use that, not any override/monkey-patch. One could of course override some `inspect` of some class and then it wouldn't show that object's class's constant path anymore, but that's then clearly the fault of that class' override. ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-102411 * 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/

Issue #19520 has been updated by Eregon (Benoit Daloze). In fact, implementing `labeled_module`/`labeled_class` like you showed above would again break these expectations, illustrating how unsafe is this API, and it's clear many people writing such tests wouldn't realize this problem (they might not even know the `labeled_module` implementation change). E.g. there are some `m = labeled_module("M")` and some `c0 = EnvUtil.labeled_class('C0') do`, but of course no constant `M` or `C0`. ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-102413 * 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/

Issue #19520 has been updated by fxn (Xavier Noria). To be clear, Zeitwerk works only with constants. When you load `foo.rb`, the constant `:Foo` has to exist in `Object`, Zeitwerk does not care if the classes or modules went through an initial anonymous period. It also does not care if the file had a `Foo` constant reference or you did a `const_set` in the expected receiver. After loading, `Foo` has to exist. Otherwise, you get an exception. ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-102425 * 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/

Issue #19520 has been updated by Dan0042 (Daniel DeLorme). Eregon (Benoit Daloze) wrote in #note-17:

IIRC naming of constants under a module is only done if a module is fully-named

Actually that's incorrect: ```ruby a = Module.new a::B = Module.new a::B.name #=> "#<Module:0x00007f6c2d474078>::B" ``` Since `a::B.name` is neither nil nor resolvable to a constant, what does it matter if it's `Controller(path/to/file.rb)::B` instead of `#<Module:0x00007f6c2d474078>::B` ? The "fake name" doesn't make the value of `a::B.name` any more or less unresolvable than it already was, but it does make it infinitely more debuggable. ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-102427 * 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/

Issue #19520 has been updated by Eregon (Benoit Daloze). @Dan0042 Right, the rule is not as simple, indeed. Of course `a::B` is not a fully-named constant here, so this is "temporary name" for `a::B`, which is what I was thinking about.

Since `a::B.name` is neither nil nor resolvable to a constant, what does it matter if it's `Controller(path/to/file.rb)::B` instead of `#<Module:0x00007f6c2d474078>::B` ? The "fake name" doesn't make the value of `a::B.name` any more or less unresolvable than it already was, but it does make it infinitely more debuggable.

This to me makes it look like the first module is accessible via constant path `Controller`. But it probably isn't, it's a lie and it's confusing. I think there is no valid reason to have anonymous modules/classes used as namespaces in non-test code. Those modules/classes used as namespaces should be named, otherwise no other part of the code can even refer to them, which would be too limiting for any real purpose. (well, they might through `const_missing` but it's nonsense to occur that overhead just to not name them) ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-102433 * 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/

Issue #19520 has been updated by psadauskas (Paul Sadauskas). FWIW, I've run into a desire for this feature on two separate occasions recently. In both cases, I'm writing an HTTP Client for an API, and want to provide a nice interface to it. The products behind the APIs are very customizable, so different customers may see different fields returned by the API, and the APIs provide a "meta" API that describes the fields and types, etc... At runtime, I want to parse the output of the Meta API, and define a Ruby Class with attributes that match. Then when I consume the regular API, its easy to initialize instances of those Classes with the data. However, since each customer of mine may have a different set of fields, and these classes may be temporary or ephemeral, I don't want to end up with a bunch of constants defined like `MyApiClient::Customer12345::Lead`, that will never get garbage collected. But, I'd still like my temporary classes to have names, since some of the libraries I'm using like Rails and Dry::Types get grumpy if given an anonymous class. I have a slight preference towards @ioquatix's proposal #19521, but either of these will solve this particular use-case. ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-102672 * 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/

Issue #19520 has been updated by ioquatix (Samuel Williams). @Dan0042 unfortunately your proposal doesn't really work for nested classes without major performance issues. ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-102919 * 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/

Issue #19520 has been updated by Dan0042 (Daniel DeLorme). ioquatix (Samuel Williams) wrote in #note-33:

@Dan0042 unfortunately your proposal doesn't really work for nested classes without major performance issues.

I sort of understand what you mean, but I think it's premature to dismiss an idea just based on the fear that it **might** have bad performance. The focus should be on whether the design/API is ok. Then **if** the implementation turns out measurably too slow **and** there is no way to remedy, the idea can be scrapped. But let's say it really is too slow to do a `rb_funcall` for each nested namespace; I can already think of an easy way to mitigate that: only call #to_s if #name is undefined. That way, performance will be unchanged for regular classes assigned to constants. And that's just the first workaround that came to mind; there may even be other ways. ```ruby x = Class.new x.new.inspect #=> #<#<Class:0x00005597d624bd28>:0x00005597d61aa3d8> def x.to_s; "hey"; end x.new.inspect #=> #<hey:0x00005597d6860998> NAMED = x x.new.inspect #=> #<NAMED:0x00005597d6845968> ``` ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-102923 * 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/

Issue #19520 has been updated by ioquatix (Samuel Williams). The difference between a dynamically defined `inspect` which can do anything vs `Module#name` which is cached are significant. I was now just writing a native Ruby extension, where I wanted a custom `rb_inspect` output. The default code for `rb_inspect` actually invokes `rb_class_name`. ```c static VALUE rb_obj_inspect(VALUE obj) { if (rb_ivar_count(obj) > 0) { VALUE str; VALUE c = rb_class_name(CLASS_OF(obj)); str = rb_sprintf("-<%"PRIsVALUE":%p", c, (void*)obj); return rb_exec_recursive(inspect_obj, obj, str); } else { return rb_any_to_s(obj); } } ``` While we in theory can change this to: ```c VALUE c = rb_inspect(CLASS_OF(obj)); ``` which is in line with your (@Dan0042) proposal, I wonder how many existing code in other places would also be copying this or using `rb_class_name`. You'd probably need to change the implementation of `rb_class_name` to call `rb_inspect`... which just seems like something that would cause regressions/issues to me. This isn't just used in `NoMethodError`... Lots of tools report the class as part of an error or even as part of the normal execution (e.g. job class serialization, IRB, etc). ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-102935 * 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/

Issue #19520 has been updated by Dan0042 (Daniel DeLorme). Eregon (Benoit Daloze) wrote in #note-39:

Why not `#<MyTemplate:0x000055e017895038 @path="path/to/file">` for an instance of MyTemplate and so no anonymous classes?

Because we want to compile the template to ruby once per process, and then use an instance for rendering: ```ruby tplclass = MyTemplate["path/to/file"] #create class and compile 'render' method (if not already done) str = tplclass.new.render(**locals) ``` This is a pretty common pattern for template engines. ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-102947 * 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/

Issue #19520 has been updated by ioquatix (Samuel Williams).

OTOH, I feel it's enough to get the file:line from the backtrace to investigate/debug/fix when a NoMethodError or similar happens with such an instance of an anonymous class.

This isn't just about exception messages. Any time such an object is printed, e.g. via `irb`, a log message, any kind of formatted output, it is less informative without the proposed feature. ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-103152 * 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/

Issue #19520 has been updated by ioquatix (Samuel Williams). As I mentioned, I think using arbitrary `#inspect` is too risky / performance issues. If you are trying to log an error, it's much safer to use a pre-existing string than to call user code (which may fail). ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520#change-103445 * 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/