--00c09f8e5d61f4a2590478896aa4
Content-Type: text/plain; charset=ISO-8859-1

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 <shugo / ruby-lang.org> wrote:

> Hi,
>
> At Tue, 17 Nov 2009 06:48:42 +0900,
> Yehuda Katz <wycats / gmail.com> 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  ctionController::Responder
> >       clear_respond_to
> >     end
> > end
>
> Do you mean that `self.responder  ctionController::Responder' can be
> replaced
> by `self.responder  esponder' 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  il, &block)
>      if base.nil?
>        @_included_block  lock
>      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 <shugo / ruby-lang.org>
>

--00c09f8e5d61f4a2590478896aa4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Shugo,</div><div><br></div><div>I agree that we should have both, but I think that the lexical scope case should win. Consider the case of RSpec:</div><div><br></div><div>describe &quot;Date&quot; do</div><div>  it &quot;equals itself&quot; do</div>

<div>        end</div><div>end</div><div><br></div><div>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,e want to be able to access class variables in the eval&#39;ed scope. I think a good solution is to add the dynamic scope _after_ the lexical scope,ather than _before_ it.</div>

<br clear="all">Yehuda Katz<br>Developer | Engine Yard<br>(ph) 718.877.1325<br>
<br><br><div class="gmail_quote">On Mon, Nov 16, 2009 at 6:41 PM, Shugo Maeda <span dir="ltr">&lt;shugo / ruby-lang.org&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Hi,<br>
<br>
At Tue, 17 Nov 2009 06:48:42 +0900,<br>
<div class="im">Yehuda Katz &lt;wycats / gmail.com&gt; wrote:<br>
</div><div class="im">&gt; For instance, you can do the following in Rails:<br>
&gt;<br>
&gt; module ActionController::MimeResponds<br>
&gt; extend ActiveSupport::Concern<br>
&gt;<br>
&gt; included do<br>
&gt; inheritable_accessor :responder, :mimes_for_respond_to,<br>
&gt; :instance_writer =&gt; false<br>
&gt; self.responder = ActionController::Responder<br>
&gt; clear_respond_to<br>
&gt; end<br>
&gt; end<br>
<br>
</div>Do you mean that `self.responder = ActionController::Responder&#39;an be replaced<br>
by `self.responder = Responder&#39; on Ruby 1.8?<br>
<br>
Then, does it really work on Ruby 1.8?<br>
I guess MimeResponds should be nested in ActionController as follows:<br>
<br>
module ActionController<br>
  
 ..<br>
<div class="im">  
end<br>
<br>
&gt; &gt; This is a wrapper around the very common:<br>
&gt;<br>
&gt; def self.included(klass)<br>
&gt; klass.class_eval do<br>
&gt; # code here<br>
&gt; end<br>
&gt; end<br>
<br>
</div>For Matz and Koichi (and other people who aren&#39;t familiar with Rails),<br>
included and append_features are overridden in ActiveSupport::Concern<br>
as follows:<br>
<br>
    멼  쿼      
  
  
<br>
   婼   ..<br>
  쨦 俨uded_block&quot;)<br>
  
  
<div class="im"><br>
&gt; Because I understand the utility in the Ruby 1.9 approach, I would like to<br>
&gt; suggest that users be allowed to choose which scoping they want. I suggest<br>
&gt; that module_eval, by default, revert to Ruby 1.8 behavior. I also suggest<br>
&gt; that we add a new method (or flag to module_eval) to enable the new<br>
&gt; behavior.<br>
<br>
</div>I basically prefer the behavior of Ruby 1.9.   should especially be lookuped like Ruby 1.9 because they can&#39;t be<br>
accessed outside of a class or its instance.   
problem may be able to fixed differently.<br>
<br>
The problem is not that Ruby 1.9 prepends the receiver of class_eval to<br>
the constant lookup path, but that a wrapper of class_eval can&#39;t be<br>
implemented on Ruby 1.9.<br>
<br>
The following program works on both Ruby 1.8 and 1.9:<br>
<br>
class Foo<br>
end<br>
<br>
module ActionController<br>
       
  
     
  
end<br>
<br>
However, the following program doesn&#39;t work on Ruby 1.9:<br>
<br>
def my_class_eval(klass, &amp;block)<br>
  쨦멼end<br>
<br>
class Foo<br>
end<br>
<br>
module ActionController<br>
       
  
     
  
end<br>
<br>
It&#39;s because class_eval prepends the reciver to the constant lookup<br>
path at the time of invocation of class_eval.    
prepends the receiver to the constant lookup path which the given block<br>
holds.<br>
<br>
I have attached a patch to fix it.   ɦ test and commit them.<br>
<font color="#888888"><br>
--<br>
Shugo Maeda &lt;shugo / ruby-lang.org&gt;<br>
</font></blockquote></div><br>

--00c09f8e5d61f4a2590478896aa4--