| From | Sent On | Attachments |
|---|---|---|
| Shugo Maeda | Oct 6, 2011 7:03 am | |
| Steve Klabnik | Oct 6, 2011 7:48 am | |
| Yukihiro Matsumoto | Oct 6, 2011 9:05 am | |
| Yukihiro Matsumoto | Oct 6, 2011 9:07 am | |
| Steve Klabnik | Oct 6, 2011 12:16 pm | |
| Bill Kelly | Oct 6, 2011 12:39 pm | |
| Yukihiro Matsumoto | Oct 6, 2011 2:49 pm | |
| Shugo Maeda | Oct 6, 2011 9:00 pm | |
| Steve Klabnik | Oct 6, 2011 10:02 pm | |
| Adam Prescott | Oct 7, 2011 2:34 am | |
| Steve Klabnik | Oct 7, 2011 12:24 pm | |
| Kurt Stephens | Oct 7, 2011 12:55 pm | |
| Yukihiro Matsumoto | Oct 7, 2011 7:39 pm |
| Subject: | [ruby-core:39996] Re: problems with Refinements | |
|---|---|---|
| From: | Steve Klabnik (ste...@steveklabnik.com) | |
| Date: | Oct 6, 2011 12:16:17 pm | |
| List: | org.ruby-lang.ruby-core | |
Unfortunately, I missed Brian's talk, so we have to wait until the video to check what he said. But when he claimed against refinements, there must be reasons behind. I am open to hear.
matz.
I don't claim to speak for Brian, and I've sent him a link to this thread, so that he can make his own statements about it, but my understanding of it is this: refinements provide very little benefit at the cost of increased complexity for both Ruby programmers and Ruby language developers.
Refinements for Rubyists: Pros: - protect a library from interference from other library's monkeypatches Cons: - End up making libraries harder to understand, since the details of MyLibrary's String are opaque from outside MyLibrary - Are a pretty complex feature to use. - This complexity makes code with refinements hard to reason about.
Refinements for Ruby Implementors: Pros: - Giving users a feature they want Cons: - Complex features are complex to implement - Refinements in particular place a large burden on send (I think), which is what makes the performance penalty so large. - This feature affects Ruby at a very, very deep level, and therefore deserves significant consideration
Finally,
"If I had asked people what they wanted, they would have said faster horses." -
Henry Ford
Many people _do_ want refinements, but that doesn't mean that it's good for Ruby. Just like 'optional typing,' when people ask for a language feature like this, what they actually want is different from what they're asking for. For example, people want optional typing because they've heard it will 'make Ruby faster,' not because they want to use optional typing to write better Ruby code. It's the same thing with Refinements. People are actually saying, "I don't have a way to know if my library will conflict with another, and what to do about it." This is a _tooling_ problem, not a language feature problem. I also personally feel that the problem is overblown. I've been doing Ruby for a few years now (though not as long as many on this list. :) ), and I don't think I've ever been particularly bitten by this issue. Maybe once or twice, and it wasn't too bad to resolve. In my mind, paying a 10%-15% performance penalty for a once-a-year bug is a bad tradeoff. I'm willing to acknowledge that it might be more of a problem with others, however, I've never actually met someone for whom that's the case.





