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

> 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.