[#33640] [Ruby 1.9-Bug#4136][Open] Enumerable#reject should not inherit the receiver's instance variables — Hiro Asari <redmine@...>

Bug #4136: Enumerable#reject should not inherit the receiver's instance variables

10 messages 2010/12/08

[#33667] [Ruby 1.9-Bug#4149][Open] Documentation submission: syslog standard library — mathew murphy <redmine@...>

Bug #4149: Documentation submission: syslog standard library

11 messages 2010/12/10

[#33683] [feature:trunk] Enumerable#categorize — Tanaka Akira <akr@...>

Hi.

14 messages 2010/12/12
[#33684] Re: [feature:trunk] Enumerable#categorize — "Martin J. Dst" <duerst@...> 2010/12/12

[#33687] Towards a standardized AST for Ruby code — Magnus Holm <judofyr@...>

Hey folks,

23 messages 2010/12/12
[#33688] Re: Towards a standardized AST for Ruby code — Charles Oliver Nutter <headius@...> 2010/12/12

On Sun, Dec 12, 2010 at 9:55 AM, Magnus Holm <judofyr@gmail.com> wrote:

[#33689] Re: Towards a standardized AST for Ruby code — "Haase, Konstantin" <Konstantin.Haase@...> 2010/12/12

On Dec 12, 2010, at 17:46 , Charles Oliver Nutter wrote:

[#33763] [Ruby 1.9-Bug#4168][Open] WeakRef is unsafe to use in Ruby 1.9 — Brian Durand <redmine@...>

Bug #4168: WeakRef is unsafe to use in Ruby 1.9

43 messages 2010/12/17

[#33815] trunk warnflags build issue with curb 0.7.9? — Jon <jon.forums@...>

As this may turn out to be a 3rd party issue rather than a bug, I'd like some feedback.

11 messages 2010/12/22

[#33833] Ruby 1.9.2 is going to be released — "Yuki Sonoda (Yugui)" <yugui@...>

-----BEGIN PGP SIGNED MESSAGE-----

15 messages 2010/12/23

[#33846] [Ruby 1.9-Feature#4197][Open] Improvement of the benchmark library — Benoit Daloze <redmine@...>

Feature #4197: Improvement of the benchmark library

15 messages 2010/12/23

[#33910] [Ruby 1.9-Feature#4211][Open] Converting the Ruby and C API documentation to YARD syntax — Loren Segal <redmine@...>

Feature #4211: Converting the Ruby and C API documentation to YARD syntax

10 messages 2010/12/26

[#33923] [Ruby 1.9-Bug#4214][Open] Fiddle::WINDOWS == false on Windows — Jon Forums <redmine@...>

Bug #4214: Fiddle::WINDOWS == false on Windows

15 messages 2010/12/27

[ruby-core:33590] Re: [Ruby 1.9-Feature#4085][Open] Refinements and nested methods

From: Yehuda Katz <wycats@...>
Date: 2010-12-06 05:41:51 UTC
List: ruby-core #33590
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
>
>

In This Thread