3 ms·

My understanding is that refinements are more of a limitation of existing monkeypatching functionality though. Like before, if you needed to monkeypatch somethi

by ufmace 13y ago

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?

ssmoot 13y ago
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.
dewind 13y ago
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 http://blog.headius.com/2012/11/refining-ruby.html
- shawn42 13y ago
  2.1 changes how the method cache works. It is now hierarchical as opposed to the old global cache.
- dragonwriter 13y ago
  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/ http://rubyrogues.com/124-rr-jruby-with-charlie-nutter/
dragonwriter 13y ago
> 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.

by ufmace 13y ago

ssmoot 13y ago

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.

dewind 13y ago

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 http://blog.headius.com/2012/11/refining-ruby.html

shawn42 13y ago
2.1 changes how the method cache works. It is now hierarchical as opposed to the old global cache.
dragonwriter 13y ago
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/ http://rubyrogues.com/124-rr-jruby-with-charlie-nutter/

dragonwriter 13y ago

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