ruby-core

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


> At least it should be forbidden to change the name of a Module multiple times.
> So from that POV that, #19520 is better.

We can make assignment fail if the name is not `nil`.

> Also the name of a Module get cached into other modules "namespaced" under that first Module.
> So it seems highly problematic to allow changing the name of a Module.

Yes, that's correct, the temporary name gets cached into nested modules,

```ruby
c = Class.new
c.class_eval("class Nested; end")

c::Nested
=> #<Class:0x00007f7f11ae6aa0>::Nested

c.class_eval("class Nested2; end")

c::Nested
=> #<Class:0x00007f7f11ae6aa0>::Nested
c::Nested2
=> fake::Nested2
```

I agree, #19520 is better in this regard.

> It can lead to confusion and lies about the program state, e.g., pretend there is Foo::Bar when there isn't, even when remove_const/const_set are not used.

As discussed, this is already the case, and can be easily replicated:

```ruby
Foo = foo = Class.new
=> Foo

Foo.class_eval("class Bar; end")
Foo::Bar
=> Foo::Bar

Object.send(:remove_const, "Foo")
=> Foo

Foo = b = Class.new
=> Foo

Foo::Bar.name
=> "Foo::Bar"

Foo::Bar
uninitialized constant Foo::Bar (NameError)
```

I agree that the proposal makes it easier to fake class names, but that functionality is already possible and thus I don't see that as an issue being introduced by this proposal.


----------------------------------------
Feature #19521: Support for `Module#name=` and `Class#name=`.
https://bugs.ruby-lang.org/issues/19521#change-102301

* 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/7483) introduces `Module#name=` (and thus also `Class#name=`) to set the temporary class name. The name assignment has no effect if the module/class already has a permanent name.

```ruby
c = Class.new do
  self.name = "fake name"
end

c = Class.new
c.name = "fake name"
```

Alternatively, we could use `set_name`:

```ruby
Class.new do
  set_name "fake_name"
end
```

Setting the name of a class changes its current name, irrespective of whether it's been assigned a permanent name, or has nested modules/classes which have cached a previous name. We might like to limit the cases where a name is set, e.g. only once, only if the name is nil, or only if it's not already permanent. There is no real harm in any of those options, just inconsistency.

## 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 do
      self.name = name
      class_eval(&block) if block
    end
  end

  def labeled_class(name, superclass = Object, &block)
    Class.new(superclass) do
      self.name = name
      class_eval(&block) if block
    end
  end
  module_function :labeled_class
```

Because the name cannot be set as part of `.new`, we have to have a separate block to set the name, before calling `class_eval`. I think the ergonomics and performance of this are slightly worse than the [counter proposal](https://bugs.ruby-lang.org/issues/19520).



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

Thread

Prev Next

In This Thread

Prev Next