Odd 'include' behaviour?

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?

Thanks,

has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org

Hi --

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?

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.

You'll see Foo listed if you do:

   p Object.ancestors

David

···

On Sun, 31 Dec 2006, has wrote:

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black\)
    (See what readers are saying! http://www.rubypal.com/r4rrevs.pdf\)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

dblack@wobblini.net wrote:

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

You'll see Foo listed if you do:

   p Object.ancestors

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?

Thanks,

has

···

--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org

has wrote:

The problem I have is that I'm using method_missing in various classes
to provide a lightweight facade.

So how can I prevent client scripts from inadvertently messing with my
modules internals?

http://facets.rubyforge.org/repo/lib/facets/more/basicobject.rb

Devin

Devin Mullins wrote:

has wrote:
> The problem I have is that I'm using method_missing in various classes
> to provide a lightweight facade.
>
> So how can I prevent client scripts from inadvertently messing with my
> modules internals?

http://facets.rubyforge.org/repo/lib/facets/more/basicobject.rb

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?

has

···

--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org