From: Yehuda Katz <wycats@...>
Date: 2010-12-06T14:41:51+09:00
Subject: [ruby-core:33590] Re: [Ruby 1.9-Feature#4085][Open] Refinements and nested methods

--0016e647ead636f1af0496b758b7
Content-Type: text/plain; charset=ISO-8859-1

I think that, for this same reason, `using` should normally not apply
outside of the immediate lexical scope. I actually believed that this was
the default behavior, and explained why I thought it was a good idea on my
blog (http://yehudakatz.com/2010/11/30/ruby-2-0-refinements-in-practice/).

In general, the most utility from refinements comes from being able to use
them freely, without worrying about accidentally breaking other code. In the
case of subclasses, for instance, I would want to be able to add a
refinement in a Rails 3.0.3 class (like ActionController::Base) for
convenience without worrying about breaking existing Rails apps that don't
expect core classes to suddenly change behavior.

I can understand the utility of offering the inherited style when desired,
but I don't think it should be the default. By default, the principle of
this feature requires that refinements modify zero code outside its lexical
scope.

Perhaps a special form of using that would also affect subclasses (for
example, for the case where Rails wants to expose ActiveSupport into its
subclasses):

class ActionController::Base
  using ActiveSupport, inherited: true
end

Yehuda Katz
Architect | Strobe
(ph) 718.877.1325


On Mon, Dec 6, 2010 at 12:12 AM, Shugo Maeda <shugo@ruby-lang.org> wrote:

> Hi,
>
> 2010/12/5 Yukihiro Matsumoto <matz@ruby-lang.org>:
> > I am neutral about local rebinding.  It is useful sometimes (as
> > someone has pointed out in this thread).  At the same time, I agree
> > with you that performance impact is a huge negative factor against
> > local rebinding.  We need more input.  Dave, what do you think?
> > Anyone else?
>
> I believe we should not support local rebinding.
>
> I guess local rebinding is not designed for refinements of classes
> which have many clients like built-in classes.  With local rebinding,
> when we refine a built-in class such as String, we have to take care
> carefully not to break existing code.  This means that, it's
> ridiculous to use the following refinement with local rebinding.
>
>  module MathN
>     refine Fixnum do
>      def /(other) quo(other) end
>    end
>  end
>
> My intention is to bring modularity into monkey patching, not to bring
> extensibility.  We already have enough extensibility in Ruby.
>
> --
> Shugo Maeda
>
>

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

I think that, for this same reason, `using` should normally not apply outsi=
de of the immediate lexical scope. I actually believed that this was the de=
fault behavior, and explained why I thought it was a good idea on my blog (=
<a href=3D"http://yehudakatz.com/2010/11/30/ruby-2-0-refinements-in-practic=
e/">http://yehudakatz.com/2010/11/30/ruby-2-0-refinements-in-practice/</a>)=
.<div>
<br></div><div>In general, the most utility from refinements comes from bei=
ng able to use them freely, without worrying about accidentally breaking ot=
her code. In the case of subclasses, for instance, I would want to be able =
to add a refinement in a Rails 3.0.3 class (like ActionController::Base) fo=
r convenience without worrying about breaking existing Rails apps that don&=
#39;t expect core classes to suddenly change behavior.</div>
<div><br></div><div><div>I can understand the utility of offering the inher=
ited style when desired, but I don&#39;t think it should be the default. By=
 default, the principle of this feature requires that refinements modify ze=
ro code outside its lexical scope.</div>
<div><br></div><div>Perhaps a special form of using that would also affect =
subclasses (for example, for the case where Rails wants to expose ActiveSup=
port into its subclasses):</div><div><br></div><div>class ActionController:=
:Base</div>
<div>=A0=A0using ActiveSupport, inherited: true</div><div>end</div><div><br=
></div><div>Yehuda Katz<br>Architect | Strobe<br>(ph) 718.877.1325<br>
<br><br><div class=3D"gmail_quote">On Mon, Dec 6, 2010 at 12:12 AM, Shugo M=
aeda <span dir=3D"ltr">&lt;<a href=3D"mailto:shugo@ruby-lang.org">shugo@rub=
y-lang.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
2010/12/5 Yukihiro Matsumoto &lt;<a href=3D"mailto:matz@ruby-lang.org">matz=
@ruby-lang.org</a>&gt;:<br>
<div class=3D"im">&gt; I am neutral about local rebinding. =A0It is useful =
sometimes (as<br>
&gt; someone has pointed out in this thread). =A0At the same time, I agree<=
br>
&gt; with you that performance impact is a huge negative factor against<br>
&gt; local rebinding. =A0We need more input. =A0Dave, what do you think?<br=
>
&gt; Anyone else?<br>
<br>
</div>I believe we should not support local rebinding.<br>
<br>
I guess local rebinding is not designed for refinements of classes<br>
which have many clients like built-in classes. =A0With local rebinding,<br>
when we refine a built-in class such as String, we have to take care<br>
carefully not to break existing code. =A0This means that, it&#39;s<br>
ridiculous to use the following refinement with local rebinding.<br>
<br>
 =A0module MathN<br>
<div class=3D"im"> =A0 =A0refine Fixnum do<br>
 =A0 =A0 =A0def /(other) quo(other) end<br>
 =A0 =A0end<br>
 =A0end<br>
<br>
</div>My intention is to bring modularity into monkey patching, not to brin=
g<br>
extensibility. =A0We already have enough extensibility in Ruby.<br>
<br>
--<br>
<font color=3D"#888888">Shugo Maeda<br>
<br>
</font></blockquote></div><br></div></div>

--0016e647ead636f1af0496b758b7--