Your mail seems to be failed to synced into bugs.ruby-lang.org, so I
reply by e-mail.

2012/11/30 Yukihiro Matsumoto <matz / ruby.or.jp>:
> |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,
(snip)
> 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.

I see.

> |* It may be better not to support nested module to simplify things.
> |  I think support for nested modules are important for refinement users,ut 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.

OK.

> |* 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.

In the current implementation the activated refinement table of a
module is shared by the code in that module definition
including refine blocks using cref.
However, to limit refinement activation only in refine blocks, cref
can't be used for that purpose, so a little hack is needed.
I think it's possible, at least in CRuby, to store hidden table in a
module, and share that table in refine blocks.

> |* 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.

I see.

> |  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.

M2->M1->C may be possible, but I worry that it makes super chain more complex.

> |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 theriginal method in the refined class to simplify the spec.
>
> So do you mean refined method appear only once in method look-up chain?

I mean that all refinements appear in the method lookup 1.blah, but
the only first found one is used, and succeeding super in C outside
the scope of using are not affected by other refinements A and B.
make sense?

> |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?

Yes.

> |Only C and X is called in the above code.
> |At first, I thought that stacking refinements and super chain are usefulor 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.

I'd like to hear other opinions, especially Charles' one.

--
Shugo Maeda