8 ms·

http://bugs.ruby-lang.org/issues/4085 http://bugs.ruby-lang.org/issues/4085 Headius technical comments on ruby tracker are a must-read. As my personal take, I

http://bugs.ruby-lang.org/issues/4085 http://bugs.ruby-lang.org/issues/4085 Headius technical comments on ruby tracker are a must-read. As my personal take, I am appalled at refinements. I think this is a bad idea solving the wrong problem.

themgt 14y ago
Thanks for linking this. I'd only glanced at refinements so far... reading these comments and example code makes my head hurt. I wouldn't have thought "solving" monkey-patching with something even more convoluted and confusing was even possible. My favorite code example is from tenderlove: class Foo < SomeParent def baz(str) cached = str.camelize ary.map {|name| cached + name} end end Could have a completely different meaning than this code: class Foo < SomeParent def baz(str) ary.map {|name| str.camelize + name} end end /lights hair on fire
andrewvc 14y ago
I wish 2.0 had focused on speed, not a bunch of features that working rubyists really don't care about. Esp. not ones this poorly thought out (you'd think given 2 years discussion they would have abandoned the idea).
- ksec 14y ago
  Speed and Memory usage. Both needs a huge improvement. And i could not understand why they are even trying with mRuby. ( I mean have they not heard of a thing called Lua and LuaJIT? ) Hopefully a lot of the tweaks and refinement will come from now to Final 2.0 release.
  - masklinn 14y ago
    > And i could not understand why they are even trying with mRuby. ( I mean have they not heard of a thing called Lua and LuaJIT? ) LuaJIT is pretty much impossible in a language with as complex semantics as Ruby (it's probably impossible in Python already, and Ruby is significantly more complex)
- VeejayRampay 14y ago
  The decision making in the Ruby world seems to be fairly centralized and not very inclusive. To see that one of core devs of one of the biggest Ruby implementations thinks it's a bad idea is really confusing to me. I really wish there had been more discussion about it before it happened. Cause now not only do we have that confusing feature which very few people seem to like, it also underlines a worrying trend where the different parts of the Ruby world don't reach a consensus before going in radical directions. No one summed it up better than Brian Ford at his RubyConf talk really: http://www.confreaks.com/videos/1278-rubyconf2012-toward-a-design-for-ruby http://www.confreaks.com/videos/1278-rubyconf2012-toward-a-d... It's a must-see.
  - molecule 14y ago
    Refinements are not yet a part of Ruby 2.0 and their implementation in Ruby 2.0 is still under discussion. As Akira Matsuda pointed out @ the same RubyConf: "Warning: Refinements are experimental and may be removed from Ruby 2.0!" [23:15] http://www.confreaks.com/videos/1275-rubyconf2012-ruby-2-0-on-rails http://www.confreaks.com/videos/1275-rubyconf2012-ruby-2-0-o...
  - djacobs 14y ago
    While I enjoyed most of Brian's talk, I wasn't particularly convinced by his dislike of refinements. Essentially, it boiled down to "this feature is hard to implement, it hides complexity, and it isn't well specified". The first and third arguments shouldn't matter to us nearly as much as the middle one. And I fail to see how namespacing monkey patches can do anything but decrease and contain accidental complexity (in the same way that method dispatch and polymorphism are better at limiting complexity than explicit conditionals).
    - jamie_ca 14y ago
      The benefit to refinements is in preventing code conflicts from a shared namespace (like monkeypatching a core class). The downside is it becomes even _harder_ to figure out what code is being run just by reading it. Right now, you just have superclasses and included modules, potentially gummed up by method_missing. Now, you need to also pay attention to refinements included by code that _calls_ the code you're looking at, which may change the way it behaves. Unless used with great care, it's going to create a nightmare debugging situation. And with some of the code I've seen, it'll happen.
- jeltz 14y ago
  They have done minor improvements to both speed and memory usage in 2.0. http://igor-alexandrov.github.com/blog/2012/11/05/yet-another-ruby-shootout/ http://igor-alexandrov.github.com/blog/2012/11/05/yet-anothe...
riffraff 14y ago
how can a problem be "wrong" ? I don't much like refinements, but conflicting monkey patches from different third party libraries _has_ been an issue over the years. The ruby community is not even the first one to notice that, there is plenty of literature on "selector namespaces" and "classboxes" from the smalltalk crowd.
- jim-greer 14y ago
  From a language designer's perspective, conflicting monkey patches seem like a problem. But if you ask Ruby users I bet 90%+ would say speed and memory usage are much bigger problems.
- vidarh 14y ago
  It has been an issue, but the much less painful solution is to be more careful about monkey patches, and employ other patterns whenever possible. In my eyes, monkey patching should only ever be considered: 1. To fix outright bugs or nasty performance issues, where the monkey patch should not have other side effects. 2. In application code, never in libraries (except as a library explicitly providing monkey patches to an application, but never as a requirement for a library to work). 3. In adding new methods, except for case 1. Of course there'd be exceptions, but very little monkey patching I see in library code is necessary or worth it. Inside your library, you have plenty of ways of avoiding the need: Wrap objects; convert objects; use helpers. Yes, it might not look as perfectly smooth, but I'd take that over trying to reason about code that relies on different sets of refinements in different scopes any day..

themgt 14y ago

Thanks for linking this. I'd only glanced at refinements so far... reading these comments and example code makes my head hurt. I wouldn't have thought "solving" monkey-patching with something even more convoluted and confusing was even possible. My favorite code example is from tenderlove: class Foo < SomeParent def baz(str) cached = str.camelize ary.map {|name| cached + name} end end Could have a completely different meaning than this code: class Foo < SomeParent def baz(str) ary.map {|name| str.camelize + name} end end /lights hair on fire

andrewvc 14y ago

I wish 2.0 had focused on speed, not a bunch of features that working rubyists really don't care about. Esp. not ones this poorly thought out (you'd think given 2 years discussion they would have abandoned the idea).

ksec 14y ago
Speed and Memory usage. Both needs a huge improvement. And i could not understand why they are even trying with mRuby. ( I mean have they not heard of a thing called Lua and LuaJIT? ) Hopefully a lot of the tweaks and refinement will come from now to Final 2.0 release.
- masklinn 14y ago
  > And i could not understand why they are even trying with mRuby. ( I mean have they not heard of a thing called Lua and LuaJIT? ) LuaJIT is pretty much impossible in a language with as complex semantics as Ruby (it's probably impossible in Python already, and Ruby is significantly more complex)
VeejayRampay 14y ago
The decision making in the Ruby world seems to be fairly centralized and not very inclusive. To see that one of core devs of one of the biggest Ruby implementations thinks it's a bad idea is really confusing to me. I really wish there had been more discussion about it before it happened. Cause now not only do we have that confusing feature which very few people seem to like, it also underlines a worrying trend where the different parts of the Ruby world don't reach a consensus before going in radical directions. No one summed it up better than Brian Ford at his RubyConf talk really: http://www.confreaks.com/videos/1278-rubyconf2012-toward-a-design-for-ruby http://www.confreaks.com/videos/1278-rubyconf2012-toward-a-d... It's a must-see.
- molecule 14y ago
  Refinements are not yet a part of Ruby 2.0 and their implementation in Ruby 2.0 is still under discussion. As Akira Matsuda pointed out @ the same RubyConf: "Warning: Refinements are experimental and may be removed from Ruby 2.0!" [23:15] http://www.confreaks.com/videos/1275-rubyconf2012-ruby-2-0-on-rails http://www.confreaks.com/videos/1275-rubyconf2012-ruby-2-0-o...
- djacobs 14y ago
  While I enjoyed most of Brian's talk, I wasn't particularly convinced by his dislike of refinements. Essentially, it boiled down to "this feature is hard to implement, it hides complexity, and it isn't well specified". The first and third arguments shouldn't matter to us nearly as much as the middle one. And I fail to see how namespacing monkey patches can do anything but decrease and contain accidental complexity (in the same way that method dispatch and polymorphism are better at limiting complexity than explicit conditionals).
  - jamie_ca 14y ago
    The benefit to refinements is in preventing code conflicts from a shared namespace (like monkeypatching a core class). The downside is it becomes even _harder_ to figure out what code is being run just by reading it. Right now, you just have superclasses and included modules, potentially gummed up by method_missing. Now, you need to also pay attention to refinements included by code that _calls_ the code you're looking at, which may change the way it behaves. Unless used with great care, it's going to create a nightmare debugging situation. And with some of the code I've seen, it'll happen.
jeltz 14y ago
They have done minor improvements to both speed and memory usage in 2.0. http://igor-alexandrov.github.com/blog/2012/11/05/yet-another-ruby-shootout/ http://igor-alexandrov.github.com/blog/2012/11/05/yet-anothe...

riffraff 14y ago

how can a problem be "wrong" ? I don't much like refinements, but conflicting monkey patches from different third party libraries _has_ been an issue over the years. The ruby community is not even the first one to notice that, there is plenty of literature on "selector namespaces" and "classboxes" from the smalltalk crowd.

jim-greer 14y ago
From a language designer's perspective, conflicting monkey patches seem like a problem. But if you ask Ruby users I bet 90%+ would say speed and memory usage are much bigger problems.
vidarh 14y ago
It has been an issue, but the much less painful solution is to be more careful about monkey patches, and employ other patterns whenever possible. In my eyes, monkey patching should only ever be considered: 1. To fix outright bugs or nasty performance issues, where the monkey patch should not have other side effects. 2. In application code, never in libraries (except as a library explicitly providing monkey patches to an application, but never as a requirement for a library to work). 3. In adding new methods, except for case 1. Of course there'd be exceptions, but very little monkey patching I see in library code is necessary or worth it. Inside your library, you have plenty of ways of avoiding the need: Wrap objects; convert objects; use helpers. Yes, it might not look as perfectly smooth, but I'd take that over trying to reason about code that relies on different sets of refinements in different scopes any day..