

Subject: [ruby-core:39996] Re: problems with Refinements

From: Steve Klabnik <steve@ e k b k o

Date: Fri, 7 Oct 2011 04:16:33 +0900

References: 39990

In-reply-to: Subject: [ruby-core:From: 39988 In-reply-to: 39990

> Unfortunately, I missed Brian's talk, so we have to wait until the > video to check what he said. =A0But when he claimed against refinements, > there must be reasons behind. =A0I am open to hear. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0matz. 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 monkeypatche= s 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 hors= es." - 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.