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

I disagree with this argument. If the feature behaved as you expected, you
would never be able to include a refinement into a scope without reading the
implementation of all callees to make sure that the refinements you included
do not conflict with methods used downstream.

Consider this (very simplified) scenario:

module ActiveSupport
  refine String do
    def camelize
      dup.split(/_/).map{ |word| word.capitalize }.join('')
    end
  end
end

And now consider some class that uses this refinement:

class Constantizer
  using ActiveSupport

  def initialize(str)
    @class_name = str.camelize
  end

  def const
    Object.const_get(@class_name)
  end
end

Now let's say that I have created my own refinement which refines camelize:

module MyApp
  refine String do
    def camelize
      "_" + capitalize + "_"
    end
  end
end

And now I go ahead and use that refinement:

class MyApp::Application
  using MyApp

  def initialize
    @cache = {}
  end

  def cache(name)
    @cache[name.camelize] = Constantizer.new(name).const
  end

  def lookup(name)
    @cache[name.camelize]
  end
end

This illustrates that when using a refinement, you would be forced to
understand the implementation of all callees, to make sure that you are not
accidentally leaking a refinement into a scope that doesn't expect it. Since
the point of encapsulating this functionality is to avoid callers needing to
know the implementation of the callee (and to allow the callee to change its
implementation as long as it doesn't modify the interface), this behavior is
unexpected.

Instead of making it easy to isolate the effects of a refinement to a scope,
those effects could leak into other scopes that do not expect to be mutated
in that way.

Essentially, by leaking the refinement, we are now making every single
method call in the callee a part of the public interface (as you believe
that the fact that #map calls #each is part of the public interface). While
we do have a few informal interfaces that behave this way, the vast majority
of Ruby code does not, and this behavior would render the feature much less
useful, and result in failure to meet the goals of the feature (the ability
to apply a refinement to an area of code without fearing breakage of other
unrelated code).

Yehuda Katz
Architect | Strobe
(ph) 718.877.1325


On Wed, Nov 24, 2010 at 11:45 AM, Dave Thomas <[e-mail]> wrote:

> Issue #4085 has been updated by Dave Thomas.
>
>
>  module Quux
>    using FooExt
>
>    foo = Foo.new
>    foo.bar  # => FooExt#bar
>    foo.baz  # => Foo#bar
>  end
>
> This behavior makes me nervous悠 can see arguments for it, but at the same
> time I can see in leading to problems, particularly in well structured
> classes where a large set of behaviors is defined in terms of one method.
> I'm sure the syntax below is wrong, but look at the spirit of it.
>
>  module DoubleEach
>    refine Array do
>      def each
>         super do |val|
>           yield 2*val
>         end
>      end
>    end
>  end
>
>  using DoubleEach
>
>  [ 1, 2, 3 ].each {|v| p v }   #=> 2, 4, 6
>
>  [ 1, 2, 3 ].min    #=> 1
>
> That would be surprising to me, as I'd expect the behavior of all the
> Enumerable methods, which depend on each, to change if I change the behavior
> of each.
> ----------------------------------------
> http://redmine.ruby-lang.org/issues/show/4085
>
> ----------------------------------------
> http://redmine.ruby-lang.org
>
>