From: Yukihiro Matsumoto <matz@...>
Date: 2012-11-30T06:13:37+09:00
Subject: [ruby-core:50342] Re: [ruby-trunk - Feature #4085] Refinements and nested methods


In message "Re: [ruby-core:50338] [ruby-trunk - Feature #4085] Refinements and nested methods"
    on Fri, 30 Nov 2012 04:05:15 +0900, "headius (Charles Nutter)" <headius@headius.com> writes:

|I assume this is so that refinement methods will see each other, yes?

Yes.

|module X
|  refine String do
|    def foo; :foo; end
|    def bar; foo; end # should be able to call foo
|  end
|end
|
|So all call sites within a refine block must look for refinements. Now...I would assume they can only see refinements in the same block, but...

No, whole refinement provided by module X can be seen from refine
block in module X.

|This is incredibly confusing to me. Why are the String refinements active within the refine Array block? That module:
|
|* Is not within the refine String block
|* Is not within a file that uses the String refinement
|* Does not refine String
|
|Why can it see the String refinements even though it's not in a "using" file and not within a refine String block?

Because it's within the body of refinement module X. Since both
refinements are defined in the same refinement, we consider they are
related (you can't see the relation from this silly examples).

|>  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).
|
|By stacking, I assume you mean something like this:
|
|class String
|  def bar; p :base; end
|end
|
|module M1
|  refine String do
|    def bar; p :m1; super end
|  end
|end
|
|module M2
|  refine String do
|    def bar; p :m2; super; end
|  end
|end
|
|using M1
|using M2
|
|"".bar # => should print :m2, :m1, :base
|
|Correct?

Correct.

|My idea of *actually* putting refinements into the hierarchy seems like it might fit this best, rather than searching two hierarchies. Will have to think about it more.

It makes refinement decoration quite unpredictable.  For example,

  module M
    refine Integer do
      def /(n); self / n.to_f; end
    end
  end
  using M
  1 / 2 # => you expect 0.5

But if refinements are searched through inheritaance hierarchy, it
won't work since there's Fixnum#/.

|>  Any more questions?
|
|Yes, lots! :)

I will answer each of them later.

							matz.