In message "Re: [ruby-core:50348] [ruby-trunk - Feature #4085] Refinements and nested methods"
    on Fri, 30 Nov 2012 10:00:34 +0900, "shugo (Shugo Maeda)" <redmine / ruby-lang.org> writes:

|>  Yes, only main.using should be available. No Module#using (for 2.0).
|
|So, the current behavior of main.using need not be changed, right?
|Technically, the current behavior of main.using is not file scope.
|The scope of main.using is from the point where using is *called at runtime* to the end of that file.
|For example,
|
|p 1 / 2     # => 0 (not refined)
|using MathN # MathN refines Fixnum#/
|p 1 / 2     # => (1/2) (refined)
|
|And a more complex example is:
|
|if false
|  using MathN
|end
|p 1 / 2     #=> 0 (not refined)

In that sense, I don't think we need to change the behavior.  What I
meant by "file scope" was that refinement only available until end of
the file.

|"Inside of refine blocks" means that all refinements defined in a module are activated
|in all refine blocks in that module and nested modules, right?

Yes, that what I meant.

|There are some considerations:
|
|* It may be better not to support nested module to simplify things.
|  I think support for nested modules are important for refinement users, but are not so important
|  for refinement authors.

I don't think nested modules are important.  We can drop them, at
least for 2.0 to simplify things.

|* It may be hard to implement efficiently activation of refinements which are defined after refine blocks.
|  For example,
|    module M
|      refine Array do
|        def to_json; "[" + map { |i| i.to_json } + "]" end
|      end
|
|      refine Hash do
|        def to_json; "{" + map { |k, v| k.to_s.dump + ":" + v.to_json } + "}" end
|      end
|    end
|  It may be better to limit refinement activation in refine blocks to refinements to be defined by the refine blocks theselves, to simplify things.  If there's no refinement activation in refine blocks, recursive methods cannot be defined, so the refinement to be defined should be activated at least.

I am not sure if I understand you correctly.  I thought method look-up
should be done in run-time.  So only I can say it that refinement M
will be available in both refine blocks in the above example.

|* Refinement activation in refine blocks may have the same problem as refinement-aware module_eval,
|  for example in the following code:
|
|    F = Proc.new { 1 / 2 }
|    module M
|      refine Fixnum do def /(other) quo(other) end end
|      refine(Object, &F)
|    end

Yes, but I consider its behavior implementation dependent.
Fundamentally you cannot expect passing proc to lambda work correctly.

|What happens if the same class is refined both in a module and another module included into that module?
|For example,
|
|  class C
|    def foo; p :C; end
|  end
|  module M1
|    refine String do def foo; p :M1; super; end; end
|  end
|  module M2
|    include M1
|    refine String do def foo; p :M2; super; end; end
|  end
|  using M2
|  C.new.foo #=> ?
|
|I think it's better to just calls M2 and C, not M1, to simplify things.
|super chain is too complex here.

I was thinking of M2->M1->C, but M2->C is simpler and acceptable.

|Charles shown an edge case.
|
|module A; refine(Numeric) { def blah; puts 'A'; super; end }; end
|module B; refine(Integer) { def blah; puts 'B'; super; end }; end
|module C; refine(Fixnum) { def blah; puts 'C'; super; end }; end
|using A; using B; using C
|1.blah
|
|Currently, only C is called, but what should happen?
|At first, I thought all blah should be called, but super in C is in scope of neither A nor B,
|it might be better not to call A and B.
|
|I'm starting to think it might be better to limit super to call only the original method in the refined class to simplify the spec.

So do you mean refined method appear only once in method look-up chain?

|For example,
|
|class X; def blah; puts 'X'; end
|module A; refine(X) { def blah; puts 'A'; super; end }; end
|module B; refine(X) { def blah; puts 'B'; super; end }; end
|module C; refine(X) { def blah; puts 'C'; super; end }; end
|using A; using B; using C
|1.blah

X.new.blah # <= do you mean X here?

|Only C and X is called in the above code.
|At first, I thought that stacking refinements and super chain are useful for aspect oriented programming.
|But refinements have no local rebinding, so it might not be a real use case of refinements.

Fair enough. If we can warn users for conflicted refinements like
above, it's even better.

							matz.