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.
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...
Agreed. Ruby is already difficult to debug on projects of any significant size, and frequeny docficut to wrap your head around where various behaviors are originating from. Ruby's dynamism is -- or was -- a strength, but it feels like the language maintainers might have taken it a bit too far.
I think there is too much pressure because of the version number. If it were 1.10 the eyes wouldn't be on it as much and they could be more incremental without anyone complaining.
This, I feel, is a rather striking difference between the development processes in ruby and python and tells more about them than any superficial language benchmark or example could.
Steve, I agree with you that this is a lot of change for something in preview, but didn't Rails 3 have some last minute changes before its release as well, and 3.1 was a big jump also?
Matz, Shugo, and Charlie will figure it out soon enough, but it is interesting. What is more upsetting to me really is the version number. 2.0 implies some major changes, but 1.9 was more major. It should be 1.10, and then they should work on something more revolutionary for 2.
There is a lot of pressure on Matz also. They really need to spend more time on it.
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).
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.
