Ruby 1.9.2 Constant Lookup with BasicObject

I

Intransition

ruby-1.9.2-p0 > module M
ruby-1.9.2-p0 ?> end
=> nil
ruby-1.9.2-p0 > class X < BasicObject
ruby-1.9.2-p0 ?> include M
ruby-1.9.2-p0 ?> end
NameError: uninitialized constant X::M
from (irb):4:in `<class:X>'
from (irb):3
from /home/trans/.rvm/rubies/ruby-1.9.2-p0/bin/irb:17:in `<main>'
 
E

Eugen Ciur

module M is defined inside Object space.
X is one level above it - it is inside BasicObject( where no Object
space is visible)
Inside X you try to include an object from other space (one level below)
I think it will work if you include Object::M
 
I

Intransition

module M is defined inside Object space.
X is one level above it - it is inside BasicObject( where no Object
space is visible)
Inside X you try to include an object from other space (one level below)
I think it will work if you include Object::M
'

I filed a bug report on Ruby's issue tracker and matz brought up the
same. Here's my take:

I see the technical reason it occurs, but to accept that as proper
behavior is going to hobble the usefulness of BasicObject.

First of all, it means one's ability to open a class and modify it
will be conditional. One will have to check if it is a BasicObject
upfront. That's easy to do if you're working with one class you
already know, but consider how it effects doing some meta-programming
where code is injected into any arbitrary class.

Worst still is that it makes importing code into a namespace very
fragile. Consider the simplistic example of having some code in a
script to eval into a module.

module M
eval(File.read('file.rb'))
end

If file.rb contains:

class R
end

class Q < BasicObject
def r; R.new; end
end

Then it will break whether we use R or ::R.

I feel the underlying issue here goes back to some other issues we've
discussed some years ago about the top-level. Routing the toplevel to
Object is not as flexible or robust as having a toplevel be an
independent self-extended module in which constant resolution would
terminate.
 
X

Xavier Noria

The rules of constant name resolution have changed with BasicObject.
There was a step before that said that if nesting and ancestors didn't
find it, you checked Object.

I'd like to know the current complete algorithm, including const_missing calls.
 
X

Xavier Noria

After some trial and error it seems the algorithm is the same as in
1.8 if we take into account that the special rule that checks Object
as a last resort applies only to modules.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,534
Members
45,008
Latest member
Rahul737

Latest Threads

Top