Project

General

Profile

Actions

Bug #21322

open

Namespaces and builtin classes as arguments and return values

Added by fxn (Xavier Noria) about 14 hours ago. Updated about 11 hours ago.

Status:
Open
Assignee:
-
Target version:
-
[ruby-core:121973]

Description

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


Related issues 1 (0 open1 closed)

Related to Ruby - Bug #21317: Namespaces leak with object IDsClosedActions

Updated by fxn (Xavier Noria) about 14 hours ago · Edited

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.

Updated by fxn (Xavier Noria) about 13 hours ago · Edited

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.

Updated by Eregon (Benoit Daloze) about 11 hours ago

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.

Actions #4

Updated by Eregon (Benoit Daloze) about 11 hours ago

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

Also available in: Atom PDF

Like0
Like0Like0Like0Like0