Live data from Hacker News

"I decided not to introduce full refinement for Ruby 2.0."

bugs.ruby-lang.org

1–10 of 25 posts

Re: "I decided not to introduce full refinement for Ruby 2.0."

#4
Repost of the message, since bugs.ruby-lang.org appears to be down:

    Issue #4085 has been updated by matz (Yukihiro Matsumoto).
    
    
    Since there still remain undefined corner case behavior in refinements, 
    and the time is running out, I decided not to introduce full refinement 
    for Ruby 2.0. The limited Ruby 2.0 refinement spec will be:
    
    * refinements are file scope
    * only top-level "using" is available
    * no module scope refinement
    * no refinement inheritance
    * module_eval do not introduce refinement (even for string args)
    
    In addition, Module#include should add refinements to included modules, 
    e.g.
    
      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
      end
    
      using R2
      "".foo
      "".bar
    
      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
      end
    
      using R2
      "".foo
      "".bar  # does not work now
    
    You can treat top-level "using" as soft-keyword, as long as it does not 
    change the behavior (but performance).
    
    Matz.

Re: "I decided not to introduce full refinement for Ruby 2.0."

#7
post #6

Anyone have an explanation on this part at the end? using R2 "".foo "".bar # does not work now I can't figure out why "".foo would work in this case but "".bar wouldn't.

edit: Disregard this, it's actually the opposite (viz. next comment) and the inheritance remark is probably only for straight class inheritance.

> no refinement inheritance

R2 included R1, which defined `bar` on String. Only the methods defined on R2 are used now with this change of plans. (I couldn't get to the ruby-lang issue, but I assume that's the reason).

Re: "I decided not to introduce full refinement for Ruby 2.0."

#8
post #7
post #6

Anyone have an explanation on this part at the end? using R2 "".foo "".bar # does not work now I can't figure out why "".foo would work in this case but "".bar wouldn't.

edit: Disregard this, it's actually the opposite (viz. next comment) and the inheritance remark is probably only for straight class inheritance. > no refinement inheritance R2 included R1, which defined `bar` on String. Only the methods defined on R2 are used now with this change of plans. (I couldn't get to the ruby-lang issue, but I assume that's the reason).

...except the previous listing does basically the same thing, but doesn't have any comment about R1's refinements not working when you're using R2.

Re: "I decided not to introduce full refinement for Ruby 2.0."

#9
post #8
post #7

Earlier quoted context omitted.

edit: Disregard this, it's actually the opposite (viz. next comment) and the inheritance remark is probably only for straight class inheritance. > no refinement inheritance R2 included R1, which defined `bar` on String. Only the methods defined on R2 are used now with this change of plans. (I couldn't get to the ruby-lang issue, but I assume that's the reason).

...except the previous listing does basically the same thing, but doesn't have any comment about R1's refinements not working when you're using R2.

Ah, I misread the feature list (namely the text right above the examples, about Module#include).

Matsumoto gives two of the same examples, the first in how he wants the feature to work (R2 having the refinements of R1 if it includes it) and the second in how it works at the moment (or doesn't work).

If you try that code it breaks, he wants it to not break and return :bar.

Re: "I decided not to introduce full refinement for Ruby 2.0."

#10
I love Ruby with all my heart but that seems to be quite a mess. While a not-well-thought-through feature in some application can be forgiven (and maybe even removed), in language design it cetainly has no place. And while this should be a secondary consideration, I really feel for those poor JRuby and Rubinus guys. As if Ruby wasnt "dynamic" enough, the sheer complexity of implementing refinements must be awful!

I think, they should just leave it out (at least for now) and rather spend some more time on performance, stabilty and memory usage in MRI...

Post reply on HN