Why is nobody using Refinements?
summary
Refinements are presented as a lexically scoped, safe alternative to global monkey‑patching, with five concrete principles showing when they activate and why blocks, reopened classes, subclasses and separate files often don’t see them; working examples include preserving an old camelize API, an RSpec‑style DSL, and a restricted‑access pattern, plus microbenchmarks that show no performance penalty and multiple demos that actually work despite unintuitive quirks—recommendation: learn the lexical scope rules and treat refinements as a safe alternative.
AI-written summary · about
chapters (16)
- 0:00Intro
- 1:41A mechanism to change the behaviour of an object in a limited and controlled way
- 9:00Refinements are activated in current and nested lexical scopes
- 11:03class hierarchy # scope hierarchy
- 12:51methods are evaluated using the lexical scope at their definition
- 13:54blocks are evaluated using the lexical scope at their definition
- 14:34Refinements use lexical scope
- 17:05Monkey patching
- 20:32Managing API changes
- 23:51Internal access control
- 27:59Lack of understanding?
- 29:52Adding using everywhere is a giant pain in the ass?
- 30:14Rails (and Ruby) doesn't use them
- 31:46Implementation quirks?
- 32:39Refinements solve a problem that nobody has?
- 33:27The rise of Object-Oriented Design?
related talks
30mRefinements - the Worst Feature You Ever Loved
32mRefinements - the Worst Feature You Ever Loved
38mRefinements - The Worst Feature You Ever Loved
47mClassboxes, nested methods, and real private methods
32mruby best practice patterns
12mImpactful Refactors: Refactoring for Readability
29mLet’s refactor some Ruby code
34mHijacking Ruby Syntax in Ruby