Issue #21322 has been updated by Eregon (Benoit Daloze). Right, IOW it's the duality between builtin classes and other classes. Builtin classes' constants, methods, ivar and cvars are all a copy per Namespace (and so potentially differ), even though for all builtin classes they are `equal?` with the corresponding builtin class in all namespaces. I think that's part of what makes the semantics of Namespace complicated, but as I understand it's also part of the design of Namespace. ---------------------------------------- Bug #21322: Namespaces and builtin classes as arguments and return values https://bugs.ruby-lang.org/issues/21322#change-113101 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- @tagomoris thanks for the docs under `doc/namespace.md`. Unless I missed it, I believe there is an edge case related to builtin classes (using the vocabulary there). Consider: ```ruby # test.rb ns = Namespace.new ns.require_relative 'foo' X = 1 ns::C.x(Object) # foo.rb class C def self.x(obj) obj::X end end ``` `obj::X` raises. I believe this is consistent with the feature, but maybe would deserve docs, because from the point of view of the Ruby programmer I am passing an object, no constant name resolution is happening in `foo.rb`. See what I mean? I believe, from my tests, that something analogous happens if `ns::C.x` returns (the namespaced) `Object`. In the main namespace, you don't get the object passed up as-is. I am also curious about how is this implemented (maybe to comment here, not necessarily in the docs). -- https://bugs.ruby-lang.org/