Bug #21322: Namespaces and builtin classes as arguments and return values

• Status: Open
• Assignee: -
• Target version: -
• Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN

[fxn (Xavier Noria)]

@tagomoris (Satoshi Tagomori) 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:

# 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).

[fxn (Xavier Noria)]

I believe this is consistent with the feature

I say so in the sense that objects with the same ID are equal in the namespace.

However, it could be argued that it is not consistent with Ruby.

Object is a constant that stores a class object, just like after X = 1 the constant X stores an integer.

So, I am doing a method call passing an object reference, and the method is not receiving the same thing.

So, there is a tension between the feature and this basic aspect of the language, in my view.

[fxn (Xavier Noria)]

For example, if I instead do

ns = Namespace.new
ns.require_relative 'foo'

c = Class.new
c::X = 1
ns::C.x(c)

then obj::X resolves as expected in the method.

Method calls somehow seem to be swapping VALUEs that correspond to builtin classes on the fly.

Please excuse I am not reading the source code to answer this myself, I do not know enough about CRuby internals to understand the patch and its implications.

[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.

[Eregon (Benoit Daloze)]

• Related to Bug #21317: Namespaces leak with object IDs added