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
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
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.
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.
···
In message “Re: warning: toplevel constant XX referenced by YY::XX” on 03/09/04, Thomas thomass@deltadata.dk writes:
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.