[#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:113541] [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 10:06:24 UTC
List:
ruby-core #113541
Issue #19681 has been updated by fxn (Xavier Noria). Philospher hat on :): I am surprised that this feature (permanent names) exists at all, really. The Ruby model does not have a tree of objects, it has a tree of modules and constants and that is all. Class and module objects are objects, they do not have the concept of belonging to anything. No different than `Object.new`. The first time a module object is assigned to a constant, it gets a name, it is a difference, yes. But from then on, they part. That name means nothing. Objects can be stored in multiple places, the original constants can be deleted, ..., you name it. In particular, you cannot even assume the object ir reachable by const getting the name. So, all attempts at trying to rely on a tree of objects are doomed to led to edge cases and inconsistencies. You are treating the objects in a way that does not exist in the Ruby language. Now, given permanent names are a thing, I believe this patch is more aligned with what you'd expect, it is more in line with what happens with regular classes and modules. ---------------------------------------- Bug #19681: The final classpath of partially named modules is sometimes inconsistent once permanently named https://bugs.ruby-lang.org/issues/19681#change-103168 * 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/