From: "fxn (Xavier Noria) via ruby-core" <ruby-core@...>
Date: 2023-05-21T09:37:18+00:00
Subject: [ruby-core:113574] [Ruby master Bug#19681] The final classpath of partially named modules is sometimes inconsistent once permanently named

Issue #19681 has been updated by fxn (Xavier Noria).


OK, I think the discussion to have in the meeting is reduced to one simple question only. Let me explain.

The behaviour I have learnt regarding temp names "owned" by other anonymous modules has test coverage [here](https://github.com/ruby/ruby/blob/4f4bc13eb92539b9e988aa27be1c1d01bd2e0fe6/spec/ruby/core/module/name_spec.rb#L37-L43), therefore this is deliberate.

That means a temp name is considered to be truly ephemeral and can eventually become *anything* (permanent). Therefore, my expectation that the trailing `::C` should be invariant in the temp name is incorrect. That test contradicts this.

So, I believe the question should be:


```ruby
m = Module.new
m::C = Class.new
m::D = m::C
M = m
M::C.name # => "M::D"
```

1. That should be "M::C", make it happen, and add a test for it.
2. Declare that to be undefined behaviour to keep things simple (if this concept exists in Ruby, not sure). You don't know which name you are going to get.

To me, both are valid resolutions. I personally only want to know which is your choice.

----------------------------------------
Bug #19681: The final classpath of partially named modules is sometimes inconsistent once permanently named
https://bugs.ruby-lang.org/issues/19681#change-103206

* Author: byroot (Jean Boussier)
* Status: Open
* Priority: Normal
* Backport: 3.0: WONTFIX, 3.1: REQUIRED, 3.2: REQUIRED
----------------------------------------
Reported to me by @fxn 

```ruby
m = Module.new

class m::C; end
p m::C.name # => "#<Module:0x000000010789fbe0>::C"

m::D = m::C
p m::D.name # => "#<Module:0x000000010789fbe0>::C"

M = m
p M::C.name # => "M::D"
```

Expected behavior:

```ruby
p M::C.name # => "M::C"
```

### Reason

When the parent is assigned its permanent classpath, we iterate over its `const_table` to recursively give a permanent name to all the constant it owns.

However, `const_table` is an `id_table` so it doesn't retain the insertion order, which means that if the constant was aliased,
we can no longer distinguish between the original name and its aliases, and whichever comes first in the `const_table` will be used as the permanent name.

### Potential solution

I have a tentative fix for it in https://github.com/ruby/ruby/pull/7829. Instead of relying on the `const_table` key, it extract the original name from the temporary classpath.
It does feel a bit wrong to do a string search in such a place, but it does work.

 



-- 
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/postorius/lists/ruby-core.ml.ruby-lang.org/