warning: toplevel constant XX referenced by YY::XX

T

Thomas

Is there a way to turn the warning in subj. into an error?

I'm trying to use const_missing to dynamically look up stuff when it
is referenced, but now I'm in trouble because e.g. System::GC does not
invoke Module#const_missing because GC is already defined at the
toplevel.

Any ideas? Isn't ruby behaving strangely here? It seems to me that
Module#const_missing is mostly useless if it doesn't work with all the
names that happen to be defined in the global scope.

Cheers,

Thomas

####### Example:

module M1
def self.const_missing(aSymbol)
puts "Looking for #{aSymbol}"
end
end

M1::Object
(irb):16: warning: toplevel constant Object referenced by M1::Object
=> Object

M1::SomethingElse
Looking for SomethingElse
=> nil
 
D

Dave Brown

: In message "Re: warning: toplevel constant XX referenced by YY::XX"
:
: |I've submitted an RCR on this now.
: |
: |http://www.rubygarden.org/article.php?sid=315
:
: I want to tell you that you are not ignored. I just don't know how to
: deal with your request yet. Do you have any idea of concrete
: behavior?

ruby -pedantic ?

--Dave
 
T

Thomas

I want to tell you that you are not ignored. I just don't know how to
deal with your request yet. Do you have any idea of concrete
behavior?

matz.

Since you ask, I don't think it is intuitive that a qualified constant
reference like MyModule::Object searches the toplevel scope. Ruby
issues an unconditional warning when this happens, so I guess neither
do you. Why not just change ruby to not search the toplevel scope for
qualified constant references? I would think few existing applications
rely on the existing behaviour.

Cheers,

Thomas
 
Y

Yukihiro Matsumoto

Hi,

In message "Re: warning: toplevel constant XX referenced by YY::XX"

|Since you ask, I don't think it is intuitive that a qualified constant
|reference like MyModule::Object searches the toplevel scope. Ruby
|issues an unconditional warning when this happens, so I guess neither
|do you. Why not just change ruby to not search the toplevel scope for
|qualified constant references? I would think few existing applications
|rely on the existing behaviour.

Yes, but I think we need to wait for a while to make a transition.
So can you wait for a moment, probably until 1.8.1?

By the way, you may have problems also for constant name conflict.

module Foo
Foo1 = 42
end

class Bar
include Foo
def Bar.const_missing(id)
id
end
end
p Bar::Foo1
p Bar::Foo2

Is it OK for you?

matz.
 
T

Thomas Sondergaard

Yes, but I think we need to wait for a while to make a transition.
So can you wait for a moment, probably until 1.8.1?

Yes, sure.
By the way, you may have problems also for constant name conflict.

module Foo
Foo1 = 42
end

class Bar
include Foo
def Bar.const_missing(id)
id
end
end
p Bar::Foo1
p Bar::Foo2

Is it OK for you?

Strictly speaking this is a problem for me, but not something that is likely
to cause too many problems in the real world.

As I see it const_missing and method_missing are called too late to serve
their purpose correctly. They should be called before looking in parent
scopes. The way it works now is probably a pragmatic (in the generic sense)
trade off, that avoids trading too much performance for a niche feature.
Maybe the real solution is to introduce a new built-in object, say,
DynamicObject that invokes the *_missing methods earlier in the resolution
sequence. This would require that method invocation and constant lookup
suffered one extra layer of indirection, but it could be implemented in C
and probably wouldn't make a noticable performance difference. Or maybe this
"dynamicity" property could just be a flag on the class, I dunno.

This is just me thinking out loud. You are the language expert, I am just a
hack.

Cheers,

Thomas
 

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
474,444
Messages
2,571,709
Members
48,796
Latest member
Greg L.
Top