Forum: Ruby-core [Ruby 1.9-Bug#3768][Open] Constant Lookup doesn't work in a subclass of BasicObject

Bug #3768: Constant Lookup doesn't work in a subclass of BasicObject
http://redmine.ruby-lang.org/issues/show/3768

Author: Thomas Sawyer
Status: Open, Priority: Normal
Category: lib
ruby -v: 1.9.2-p0

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>'

Issue #3768 has been updated by Usaku NAKAMURA.

Status changed from Open to Assigned
Assigned to set to Yukihiro Matsumoto

I think it's spec, but we should hear the opinion of matz.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/3768

Hi,

BasicObject does not inherit from Object, where the constant M is
defined.  So, if you want to refer the toplevel constant M, try ::M.

              matz.

In message "Re: [ruby-core:31956] [Ruby 1.9-Bug#3768][Open] Constant 
Lookup doesn't work in a subclass of BasicObject"
    on Tue, 31 Aug 2010 04:08:13 +0900, Thomas Sawyer 
<redmine@ruby-lang.org> writes:
|
|Bug #3768: Constant Lookup doesn't work in a subclass of BasicObject
|http://redmine.ruby-lang.org/issues/show/3768

|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>'

Issue #3768 has been updated by Thomas Sawyer.


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.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/3768