5 ms·

Ruby 2.0 Refinements in Practice

82 points by wycats 16y ago

SlyShy 16y ago
Part of my interest in _why's project Potion was the use of scoped mixins. Seeing that Ruby will have a similar capability soon is exciting to me, as I can think of several instances where I've wanted to avoid leaking a localized monkey-patch.
adambyrtek 16y ago
Looks very interesting and this could finally address the biggest gripe against Ruby, which is uncontrolled monkey patching leading to interactions between libraries.
riffraff 16y ago
I remember the proposal of "ruby behaviours" from david black about ten years ago[1] which allowed doing the same. Nice to see it finally being implemented in the core language. [1]http://www.wobblini.net/ruby/behaviors/ http://www.wobblini.net/ruby/behaviors/
davnola 16y ago
Can anyone please explain why ruby-core prefer refinements over classboxes?
- steveklabnik 16y ago
  I'm no expert on classboxes, but there's some info here: http://timeless.judofyr.net/refinements-in-ruby http://timeless.judofyr.net/refinements-in-ruby (control-f for 'classb') I'd imagine that some of the reason is due to the fact that this is already implemented, but classboxes are not. I don't know anything about ruby-core, so I don't know how much that'd matter to them, but an almost identical but implemented feature seems much better than a more pure but unimplemented one.
  - davnola 16y ago
    The proposer suggests here http://goo.gl/4P4Wa http://goo.gl/4P4Wa (slide 39) and here http://goo.gl/p7ReQ http://goo.gl/p7ReQ that local rebinding violates the expectations of the callee, but it just seems to me to be very unintuitive.
pilif 16y ago
What interests me personally, also in light of this snarky comment here http://news.ycombinator.com/item?id=1924487 http://news.ycombinator.com/item?id=1924487 is whether Ruby 2.0 will do away with reopening classes and only allow the much better Refinements. This will break most of the code out there, but in light of doing it cleanly, it would probably need to be done. On the other hand, a change like that will make sure that we might never see significant adoption of Ruby 2
- xtho 16y ago
  I don't know. I think it would be better to have ruby 1.8 and ruby 2.0 around and to state clearly that some code requires this or that version than having to deal with ruby 1.9 that is still close to 1.8 but not close enough not to break code.
- pygy_ 16y ago
  I don't think that editable classes and modules will go away, since they allow to spread the definition of a class to multiple file and/or serve as namespaces.
bensummers 16y ago
It's worth reading Charles Nutter's thoughts on the performance of implementing this language feature: http://groups.google.com/group/ruby-core-google/msg/7ccc375905dda23c http://groups.google.com/group/ruby-core-google/msg/7ccc3759... JRuby seems rather important these days. I wonder if that gives the project an effective veto on (bad) language features?
- compay 16y ago
  Veto, no, but obviously the JRuby team are well worth listening to. Charles's post isn't really saying that refinements are a bad idea, but rather offering some, well, "refinements" to how he thinks they should be implemented. It's taken a long time to get Ruby's performance up to the respectable levels it finally achieves with 1.9 and JRuby, so I'm glad to see Charles pushing to avoid letting features creep in which could seriously degrade it.
  - bensummers 16y ago
    I can't imagine them having an actual veto, but they are definitely worth listening to.
- ekidd 16y ago
  Ruby is already the slowest widely-used programming language, by a fairly significant margin. Ruby 1.8.7 routinely runs a 1/200th the speed of C code. For comparison, other dynamic languages run at 1/2th to 1/60th the speed of C. This is better in Ruby 1.9 (getting up into the 1/60th range). But Ruby is still a painfully slow language. Some unscientific benchmark plots here (note the log scale!): http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php?gpp=on&java=on&luajit=on&ghc=on&sbcl=on&racket=on&v8=on&jruby=on&python3=on&yarv=on&ruby=on&calc=chart http://shootout.alioth.debian.org/u32/which-programming-lang... JRuby and Rubinius have been working to improve Ruby performance. In theory, it might possible for Ruby to run at 1/2th to 1/10th the speed of C using an aggressive tracing and optimizing compiler similar to LuaJIT. But this proposed feature really makes me cringe: If refinements require frequently invalidating method caches, Ruby performance will always be horrible. I'd rather sacrifice a tiny amount of expressiveness and have my code run 50x faster, thank you. :-) EDIT: Note that there are some very cheap ways to implement a similar feature, including the way Common LISP supports package-scoped symbols.
CoffeeDregs 16y ago
I recently and very reluctantly switched from Ruby+Rails to Python+Django. I really preferred Ruby's syntax: to me, it's just prettier and cleaner than Python. I really preferred Rails' organization: less flexible than Django means faster development when my projects fit into Rails' organization... ... but YKatz's article gives me comfort that I made the right decision. While you can accomplish many of the same bits of magic in Python, it's much harder to do so. Clearly, I'm not a Ruby ninja, but I am someone trying to get stuff done and the pervasiveness of monkey-patching in Rails bit me a number of times (track down some function only to find out that I was looking at the wrong, un-monkey-patched version). I hadn't really realized how much I don't miss Ruby until reading through YKatz's article on how Ruby 2.0 will handle monkey-patching. How about just making monkey-patching harder? Python has plenty of complexity, but you don't need to know about it: you can use Django just fine without paying much attention to the richness of Python. Ruby also has plenty of complexity and you need to know about it: use Rails or add a plugin to Rails and you'll quickly be reading through complicated Ruby classes that monkey-patch Rails.

82 points by wycats 16y ago

Part of my interest in _why's project Potion was the use of scoped mixins. Seeing that Ruby will have a similar capability soon is exciting to me, as I can think of several instances where I've wanted to avoid leaking a localized monkey-patch.

adambyrtek 16y ago

Looks very interesting and this could finally address the biggest gripe against Ruby, which is uncontrolled monkey patching leading to interactions between libraries.

riffraff 16y ago

I remember the proposal of "ruby behaviours" from david black about ten years ago[1] which allowed doing the same. Nice to see it finally being implemented in the core language. [1]http://www.wobblini.net/ruby/behaviors/ http://www.wobblini.net/ruby/behaviors/

davnola 16y ago

Can anyone please explain why ruby-core prefer refinements over classboxes?

steveklabnik 16y ago
I'm no expert on classboxes, but there's some info here: http://timeless.judofyr.net/refinements-in-ruby http://timeless.judofyr.net/refinements-in-ruby (control-f for 'classb') I'd imagine that some of the reason is due to the fact that this is already implemented, but classboxes are not. I don't know anything about ruby-core, so I don't know how much that'd matter to them, but an almost identical but implemented feature seems much better than a more pure but unimplemented one.
- davnola 16y ago
  The proposer suggests here http://goo.gl/4P4Wa http://goo.gl/4P4Wa (slide 39) and here http://goo.gl/p7ReQ http://goo.gl/p7ReQ that local rebinding violates the expectations of the callee, but it just seems to me to be very unintuitive.

pilif 16y ago

What interests me personally, also in light of this snarky comment here http://news.ycombinator.com/item?id=1924487 http://news.ycombinator.com/item?id=1924487 is whether Ruby 2.0 will do away with reopening classes and only allow the much better Refinements. This will break most of the code out there, but in light of doing it cleanly, it would probably need to be done. On the other hand, a change like that will make sure that we might never see significant adoption of Ruby 2

xtho 16y ago
I don't know. I think it would be better to have ruby 1.8 and ruby 2.0 around and to state clearly that some code requires this or that version than having to deal with ruby 1.9 that is still close to 1.8 but not close enough not to break code.
pygy_ 16y ago
I don't think that editable classes and modules will go away, since they allow to spread the definition of a class to multiple file and/or serve as namespaces.

bensummers 16y ago

It's worth reading Charles Nutter's thoughts on the performance of implementing this language feature: http://groups.google.com/group/ruby-core-google/msg/7ccc375905dda23c http://groups.google.com/group/ruby-core-google/msg/7ccc3759... JRuby seems rather important these days. I wonder if that gives the project an effective veto on (bad) language features?

compay 16y ago
Veto, no, but obviously the JRuby team are well worth listening to. Charles's post isn't really saying that refinements are a bad idea, but rather offering some, well, "refinements" to how he thinks they should be implemented. It's taken a long time to get Ruby's performance up to the respectable levels it finally achieves with 1.9 and JRuby, so I'm glad to see Charles pushing to avoid letting features creep in which could seriously degrade it.
- bensummers 16y ago
  I can't imagine them having an actual veto, but they are definitely worth listening to.
ekidd 16y ago
Ruby is already the slowest widely-used programming language, by a fairly significant margin. Ruby 1.8.7 routinely runs a 1/200th the speed of C code. For comparison, other dynamic languages run at 1/2th to 1/60th the speed of C. This is better in Ruby 1.9 (getting up into the 1/60th range). But Ruby is still a painfully slow language. Some unscientific benchmark plots here (note the log scale!): http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php?gpp=on&java=on&luajit=on&ghc=on&sbcl=on&racket=on&v8=on&jruby=on&python3=on&yarv=on&ruby=on&calc=chart http://shootout.alioth.debian.org/u32/which-programming-lang... JRuby and Rubinius have been working to improve Ruby performance. In theory, it might possible for Ruby to run at 1/2th to 1/10th the speed of C using an aggressive tracing and optimizing compiler similar to LuaJIT. But this proposed feature really makes me cringe: If refinements require frequently invalidating method caches, Ruby performance will always be horrible. I'd rather sacrifice a tiny amount of expressiveness and have my code run 50x faster, thank you. :-) EDIT: Note that there are some very cheap ways to implement a similar feature, including the way Common LISP supports package-scoped symbols.

CoffeeDregs 16y ago

I recently and very reluctantly switched from Ruby+Rails to Python+Django. I really preferred Ruby's syntax: to me, it's just prettier and cleaner than Python. I really preferred Rails' organization: less flexible than Django means faster development when my projects fit into Rails' organization... ... but YKatz's article gives me comfort that I made the right decision. While you can accomplish many of the same bits of magic in Python, it's much harder to do so. Clearly, I'm not a Ruby ninja, but I am someone trying to get stuff done and the pervasiveness of monkey-patching in Rails bit me a number of times (track down some function only to find out that I was looking at the wrong, un-monkey-patched version). I hadn't really realized how much I don't miss Ruby until reading through YKatz's article on how Ruby 2.0 will handle monkey-patching. How about just making monkey-patching harder? Python has plenty of complexity, but you don't need to know about it: you can use Django just fine without paying much attention to the richness of Python. Ruby also has plenty of complexity and you need to know about it: use Rails or add a plugin to Rails and you'll quickly be reading through complicated Ruby classes that monkey-patch Rails.