[#113435] [Ruby master Feature#19634] Pattern matching dynamic key — "baweaver (Brandon Weaver) via ruby-core" <ruby-core@...>
Issue #19634 has been reported by baweaver (Brandon Weaver).
6 messages
2023/05/09
[#113489] [Ruby master Bug#19642] Remove vectored read/write from `io.c`. — "ioquatix (Samuel Williams) via ruby-core" <ruby-core@...>
Issue #19642 has been reported by ioquatix (Samuel Williams).
10 messages
2023/05/15
[ruby-core:113570] [Ruby master Bug#19681] The final classpath of partially named modules is sometimes inconsistent once permanently named
From:
"fxn (Xavier Noria) via ruby-core" <ruby-core@...>
Date:
2023-05-20 22:29:52 UTC
List:
ruby-core #113570
Issue #19681 has been updated by fxn (Xavier Noria). @byroot agree we are reaching a point in which we need some authoritative answer saying: This is how it is supposed to work. I was surprised by the edition of names you do not "own", I had never tried this. I'd expect those to be skipped. However, I realized this has a consequence for the proposed patch we need to be aware of. Let's consider ```ruby m = Module.new m::C = Class.new n = Module.new n::C = Class.new n::D = m::C ``` with this patch, `N::C` and `N::D` are different class objects, but their name is the same: "N::C". For some points of view, this could be counterintuitive. For others, this is might be a fine edge case, since and class names and constant paths are totally decoupled in the Ruby design anyway. This decoupling is real. For example, if you have a reloadable module `M` and you include it in `ActiveRecord::Base` (this is wrong, but technically possible), on reload, the ancestor chain of `ActiveRecord::Base` has a module object that is different from the one stored in `M`, but has the same name, "M". So, in Ruby class/mod names are not guaranteed or assumed to be unique. In that sense, it might be seen as fine. We need an authoritative guide. ---------------------------------------- Bug #19681: The final classpath of partially named modules is sometimes inconsistent once permanently named https://bugs.ruby-lang.org/issues/19681#change-103203 * 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 -- [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/