[ruby-core:26777] Re: Ruby constant lookup

Shugo,

I agree that we should have both, but I think that the lexical scope case
should win. Consider the case of RSpec:

describe "Date" do
  it "equals itself" do
    Date.today.should == Date.today
  end
end

If we use dynamic scope first, then if RSpec adds Spec::Date, it will
suddenly break this spec. Lexical scope is more intuitive, and is expected
by many normal uses today. On the other hand, we want to be able to access
class variables in the eval'ed scope. I think a good solution is to add the
dynamic scope _after_ the lexical scope, rather than _before_ it.

Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325


On Mon, Nov 16, 2009 at 6:41 PM, Shugo Maeda <[e-mail]> wrote:

> Hi,
>
> At Tue, 17 Nov 2009 06:48:42 +0900,
> Yehuda Katz <[e-mail]> wrote:
> > For instance, you can do the following in Rails:
> >
> > module ActionController::MimeResponds
> >   extend ActiveSupport::Concern
> >
> >     included do
> >       inheritable_accessor :responder, :mimes_for_respond_to,
> > :instance_writer => false
> >       self.responder = ActionController::Responder
> >       clear_respond_to
> >     end
> > end
>
> Do you mean that `self.responder = ActionController::Responder' can be
> replaced
> by `self.responder = Responder' on Ruby 1.8?
>
> Then, does it really work on Ruby 1.8?
> I guess MimeResponds should be nested in ActionController as follows:
>
> module ActionController
>  module MimeResponds
>    ...
>   end
> end
>
> > > This is a wrapper around the very common:
> >
> > def self.included(klass)
> >   klass.class_eval do
> >     # code here
> >   end
> > end
>
> For Matz and Koichi (and other people who aren't familiar with Rails),
> included and append_features are overridden in ActiveSupport::Concern
> as follows:
>
>    def included(base = nil, &block)
>      if base.nil?
>        @_included_block = block
>      else
>        super
>      end
>    end
>
>    def append_features(base)
>      if super
>        ...
>        base.class_eval(&@_included_block) if
> instance_variable_defined?("@_incl
> uded_block")
>      end
>    end
>
> > Because I understand the utility in the Ruby 1.9 approach, I would like
> to
> > suggest that users be allowed to choose which scoping they want. I
> suggest
> > that module_eval, by default, revert to Ruby 1.8 behavior. I also suggest
> > that we add a new method (or flag to module_eval) to enable the new
> > behavior.
>
> I basically prefer the behavior of Ruby 1.9.  I think class variables
> should especially be lookuped like Ruby 1.9 because they can't be
> accessed outside of a class or its instance.  Then, I guess your
> problem may be able to fixed differently.
>
> The problem is not that Ruby 1.9 prepends the receiver of class_eval to
> the constant lookup path, but that a wrapper of class_eval can't be
> implemented on Ruby 1.9.
>
> The following program works on both Ruby 1.8 and 1.9:
>
> class Foo
> end
>
> module ActionController
>  Responder = "This is a Responder"
>  module MimeResponds
>    Foo.class_eval do
>      p Responder
>    end
>  end
> end
>
> However, the following program doesn't work on Ruby 1.9:
>
> def my_class_eval(klass, &block)
>  klass.class_eval(&block)
> end
>
> class Foo
> end
>
> module ActionController
>  Responder = "This is a Responder"
>  module MimeResponds
>    my_class_eval(Foo) do
>      p Responder
>    end
>  end
> end
>
> It's because class_eval prepends the reciver to the constant lookup
> path at the time of invocation of class_eval.  I think it should
> prepends the receiver to the constant lookup path which the given block
> holds.
>
> I have attached a patch to fix it.  If it's acceptable, I'll write a
> test and commit them.
>
> --
> Shugo Maeda <[e-mail]>
>