[develop7]

I wonder why this otherwise thorough post doesn't mention almost decade-old feature called "refinements" [1]?

1: https://ruby-doc.org/core-2.5.3/doc/syntax/refinements_rdoc....

[Lio]

I don't know the authors reason but I've personally always avoided refinements after first reading about their performance hit for JRuby code[0].

I read somewhere recently that even for MRI ruby you can take a 40% hit when using refinements (but please take that with a big pinch of salt as I can't find the source right now).

0. http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/...

[byroot]

The source is me: https://gist.github.com/casperisfine/1c46f05cccfa945cd156f44...

Note that this overhead apply as soon as a refinement is defined for a method regardless of wether it's ever active.

That 40% figure is for an empty method. So for "big" methods that are infrequently called it's probably fine, but it should really be avoided in hotspots.

[eloisius]

Not sure why the author chose not to, but personally I’ve avoided use of refinements because of the weird, stateful way that it changes the implementation of a class. It’s too confusing to scan the code quickly and know whether a particular class has a refinement activated in a particular scope. Ideally don’t monkey patch things, wrap them in your own class that decorates a stdlib class. If you can’t do that, my personal preference is to have the monkey patched class be consistently monkey patched on all scopes.

[petepete]

I use refinements in a couple of my projects, they definitely feel like the right approach, especially in a library where you don't want unintended consequences.

Admittedly they're a bit of a mystery to lots of devs.

[pankajdoharey]

Absolutely, refinements are the most legit way of monkeypatching. I could almost bet the author doesnt know about it, had he known there is no way anyone would forego mentioning it when it was specifically introduced to address the title of the post.