From: Robert Klemme <shortcutter@...>
Date: 2012-05-10T06:02:40+09:00
Subject: Re: change namespace scope / nesting problem

On Wed, May 9, 2012 at 5:35 PM, Jan E. <lists@ruby-forum.com> wrote:
> I think in the current version of Ruby, constants are always looked up
> lexically (this is different from past versions). So you may not be able
> to reference the constant in the context of "base".

I don't think I would call this behavior "lexical lookup":

irb(main):001:0> class A; class Helper; def x; "in A" end end end
=> nil
irb(main):002:0> class B; class Helper; def x; "in B" end end end
=> nil
irb(main):003:0> [A,B].map {|cl| cl::Helper.new.x}
=> ["in A", "in B"]
irb(main):004:0> RUBY_VERSION
=> "1.9.3"

> Anyway, I generally find it a bad idea to rely on obscure lookup paths.
> Even it *did* work, it would be difficult to track where the constant
> actually comes from. I'd rather restructure the classes and modules.

Right.  It's a bad idea to require Mixins::A to know something about
the environment of the class passed to #included.  One way out would
be to nest Helper in the class in the same way I demonstrated above.

But then, the class_eval is superfluous because the method could be
simply defined in Mixin::A to achieve the same effect of defining a
method for all instances:

module Mixins::A
  def test_it
    # Helper here does not make sense, unless it's
    self.class::Helper
  end
end

Iuri, why do you think you need to construct the code you showed?
There's probably another - better - way.  For example, you could add
an instance method helper which returns the class, e.g.

module Mixins
  module A
    def test_it
      helper
    end
  end
end

module Foo
 class Helper
 end

 class Bar
   include ::Mixins::A
   def helper; Helper; end
 end

end

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/