Hacker News Reader

Comment by jrochkind1 | Hacker News Reader

Refinements, why, matz, why?

In a large complex program with many dependencies, they are going to make debugging an nightmare, figuring out where the method you were calling is actually defined. And lead to weird hard to diagnose bugs where you call a method with a differnet definition than you expected.

And the use cases that justify refinements is entirely large complex programs with many dependencies, right? They're supposed to actually _reduce_ bugs and debugging challenges from monkeypatching... but nobody seems to actually think they do except matz.

Is _anyone_ who works on well-known large complex programs with many dependencies -- actually on record as supporting refinements, subsequent to the analyses that showed what a mess they'd become?

Why, matz, why?

View on HN

My understanding is that refinements are more of a limitation of existing monkeypatching functionality though. Like before, if you needed to monkeypatch something, you had to re-define the method system-wide. This seems like it allows you to have the monkeypatch only apply in the modules that you need it to, and to define it with a special refine keyword that's easy to search for.

Then again, many of the major gems that I've worked with so far define methods in various dynamic ways, making it challenging to figure out what code it's actually running. Hello ActiveRecord?

You could always extend the singleton object before to avoid global monkey-patching.

But the real lesson is probably just if you're not writing ActiveSupport, don't do global monkey patches at all. Favor inheritance and composition. Especially in your own libraries where it's easier to ensure a global patch doesn't break your code.

I'll refer to Nutter on this one. Refinements appear to be a method caching nightmare.

http://blog.headius.com/2012/11/refining-ruby.html

2.1 changes how the method cache works. It is now hierarchical as opposed to the old global cache.

Those concerns voiced with 2.0's refinements before release were why they were marked as experimental, and were the driving force behind the changes made to refinements between 2.0 and 2.1.

On the 2.1, non-experimental version, he has said: "What we’re going to have as refinements in 2.1 is a paired down version that I think still provides the bulk of the functionality people wanted out of the feature without most of the pain that I was concerned about originally."

http://rubyrogues.com/124-rr-jruby-with-charlie-nutter/

> My understanding is that refinements are more of a limitation of existing monkeypatching functionality though.

They are an alternative rather than a limitation, since you can still do regular monkeypatching, you just now have an option to do things that are less intrusive.

You can always not upgrade. It's not a fun option, but an option never-the-less. Or just don't use refinements.

Seeing as other ruby implementations (rubinius and jruby) have been very iffy on refinements and may not implement them it is probably best not to use them at all if possible.

Charles Nutter (of JRuby) has said that many of his main complaints on refinements have been resolved. His original rant can be found here: http://blog.headius.com/2012/11/refining-ruby.html

Ooo excellent news, I didnt know that.

I won't use refinements, but if open source code I'm using uses them, I still get to debug them.

Yes, yes, I know, I can analyze any open source code before using it and not use it if it uses refinements, or I can simply never use any Not Invented Here code at all.

I can do many things, it is indeed a wonderful free country.

Reply on news.ycombinator.com