> I am not sure why
> you concluded refinements make libraries hard to understand.

Sorry, this was terrible wording on my part. What I was trying to say
was the converse; I don't think they make it any _easier_. Which is
almost a different statement. I don't feel that refinements are an
actual win for clarity in any way.


> At this point, I think refinements are better than monkey patching
> because affection of refinements are limited lexically.

Right. I'm concerned that by making them more limited, it'll encourage
the proliferation of doing these kinds of custom extensions. Since
they're 'safer,' they'll be used more often.

Is patching core classes something we want to actively encourage? At
least with monkeypatching being a bit 'dangerous,' people think twice
before they do it. If we make it easier, and people have their own
custom strings everywhere, the extra overhead there will get out of
hand. I want Strings to be Strings 99% of the time, and special
strings only sometimes.

> I admit that refinements are complex, but refinements are a feature
> for advanced library/framework developers.
> Most application programmers do not need to take care about the
> complexity of refinements.

Sure. And I'm not opposed to adding something strictly due to
complexity; some would call blocks complex, for example, but they're
my favorite feature of Ruby. However, what I see in refinements is
adding extra complexity and a drop in performance for very, very
little gain.

> Agreed. =A0I think Matz should finally decide.

Absolutely, 100%. Of course, it's Matz' language, but that doesn't
mean others can't make a case to persuade him one way or the other. :)
But what he says goes.