Issue #21322 has been updated by fxn (Xavier Noria). @eregon maybe, but the fact is that you pass an object, and the callee receives a different object. This is not consistent with the current language. Ideas: * Introduce the concept of "namespace-level root objects", documented to be swapped on the fly or something. Sounds too ad-hoc. * Restricting method calls to primitive types. * Disallowing cross-namespace constant access or method calls. The last one would also fix that the design allows mixing objects from different versions of the same gem. Implementation details aside, some conceptual solution has to be devised to make this sound. BTW, my examples are synthetic. But for more practical minds, that `Object` could be an attribute three levels down the object tree from your namespace-level class instance. ---------------------------------------- Bug #21322: Namespaces and builtin classes as arguments and return values https://bugs.ruby-lang.org/issues/21322#change-113126 * 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/