Wondering if the following behaviour is a bug or a feature:
#######
module Foo
class Bar
end
def baz
end
end
o = Foo::Bar.new
p respond_to?(:baz) # false
p o.respond_to?(:baz) # false
include Foo
o = Bar.new
p respond_to?(:baz) # true
p o.respond_to?(:baz) # true <------ shouldn’t this be false?
#######
‘include Foo’ adds Bar and baz to the top-level namespace as expected.
What I don’t understand is why baz should also appear as a method of
Bar. Anyone know what’s going on here?
‘include Foo’ adds Bar and baz to the top-level namespace as expected.
What I don’t understand is why baz should also appear as a method of
Bar. Anyone know what’s going on here?
Try adding this:
p “hi”.respond_to?(:baz) # true
By including Foo at the top level, you’ve mixed it into Object. So
every object now includes Foo in its method lookup path.
Okay, so if I understand correctly: main is an instance of Object. This
means that calling include on main adds methods to every object in the
program, including those in imported modules. However, given that:
require “somemodule”
include SomeModule
seems to be the standard idiom for adding a module’s classes and
methods directly to a main script, isn’t this also rather unsafe seeing
as it breaks module encapsulation?
The problem I have is that I’m using method_missing in various classes
to provide a lightweight facade. This is fine as long nobody goes
accidentally injecting extra methods into those classes (or their
superclasses) - but if that happens then those methods are called
instead of method_missing, and the facade objects no longer work
correctly.
So how can I prevent client scripts from inadvertently messing with my
modules internals?
Many thanks. Took a few hours to figure it out (it needed some changes)
but eventually got it working and it seems to have solved the problem.
Can’t say I’m entirely comfortable with the thought of my modules
having to put traps into Object/Module/Class though. Could other users
have a problem with that?