From: Yukihiro Matsumoto <matz@...>
Date: 2012-11-29T23:06:03+09:00
Subject: [ruby-core:50329] Re: [ruby-trunk - Feature #4085] Refinements and nested methods

In message "Re: [ruby-core:50299] [ruby-trunk - Feature #4085] Refinements and nested methods"
    on Thu, 29 Nov 2012 15:02:03 +0900, "shugo (Shugo Maeda)" <redmine@ruby-lang.org> writes:

|> * refinements are file scope
|> * only top-level "using" is available
|> * no module scope refinement
|
|Do these constraints just mean that main.using is available, but Module#using is not?

Yes, only main.using should be available. No Module#using (for 2.0).

|How should the following code behave?
|
|module R
|  refine String do
|    def foo; p :foo; end
|  end
|  "".foo # (a)
|end
|"".foo   # (b)
|
|Currently, (a) prints :foo, and (b) raises a NoMethodError.

Refinements will be available only from:

* the scope where refinements are added by calling "using"
* or inside of refine blocks

Inside of refine blocks (not whole module scope) might be
controversial, but I think it's OK to restrict refinements there.  As
a result, both (a) and (b) raise NoMethodError.  But "".foo can be called
from within the refine block.

|And, how about the following example, where a nested module is defined?
|
|module R
|  refine String do
|    def foo; p :foo; end
|  end
|
|  module M
|    "".foo
|  end
|  "".foo
|end
|"".foo

Every "".foo in the above example should raise NoMethodError, because
they are outside of refine blocks.  I admit I've been less careful
about nested refinement modules.  For nested refinement modules, it
should behave as following:

>module R
>  refine String do
>    def foo; p :foo; end
>  end
>
>  module M
>    refine Array do
>      "".foo  # => OK
>    end
>  end
>end
>
>using R::M
> "".foo  # => NG

|> In addition, Module#include should add refinements to included modules, e.g.
|
|This is very different from the current feature, so we need a discussion about it.
|What does "add refinements" mean here?
|There are two aspects about refinement addition.  They are defined in modules by Module#refine, and activated in certain scopes by using.
|Does "to add refinements" mean to define (or inherit indirectly) refinements in modules, or to activate refinements in modules, or both of them?

I meant included module will provide refinement of combination of including
module(s) and the module itself.

|For example, how should the following code behave?
|
|  module R1
|    refine String do
|      def bar
|        p :bar
|      end
|    end
|  end
|
|  module R2
|    include R1
|    refine String do
|      def foo
|        p :foo
|      end
|    end
|    "".foo
|    "".bar
|  end

Since all calls of "".foo and "".bar are outside of refine blocks,
they should raise NoMethodError.  But R2 should provide refinement to
add method #bar and #foo to String class.

|Finally, how super in refinements should behave in the new spec?

Refinements should come before normal methods, so super in the normal
method will not see a refined method, and super in the refined method
will see a normal method (or other refined method if refinements are
stacked).

The whole point is separation of defining refinements (for library
developers) and using refinements (for library users).

Any more questions?

							matz.