Re: Stop picking on alias_method_chain
Both Ben and Yehuda are wrong.
They both use messy metaprogramming where Ruby has a nice solution already. It is a chain of modules and a super method.
If the base functionality is provided in a module it looks like this:
module BaseFeatures
def hello
"Hello, world!"
end
end
module AnyGreetingPlugin
def hello(arg = "world")
super.sub(/world/, arg)
end
end
class MyConfiguration
include BaseFeatures
include AnyGreetingPlugin
include AnotherPlugin
end
class MyConfiguration < BaseFeatures
include AnyGreetingPlugin
include AnotherPlugin
end
Now let me respond to each point from the Ben’s article:
1. “The method names don’t properly describe what is going on”. Module name describes what particular functionality it adds to the methods it contains.
2. “The base method shouldn’t care what other modules are doing, modularity is broken”. That’s not the case when you use regular modules.
3. “Logic is not 100% contained”. Logic is 100% contained: no magical macros anywhere.
4. “Promotes messy code”. Again, nothing to even seem messy.
5. “Exposes a documentation flaw”. When you think modules it is easy to separate concerns and understand how every little aspect of functionality affects everything else. You don’t have to speak any other language except Ruby. You think of module chains and message passing: no structure is created dynamically where not necessary. Only thing you have to do: describe in the documentation what this particular class or module is supposed to do. Then provide examples of a default configurations (when some modules are included in a single class) to make the picture complete. Respect the language. Keep it simple, stupid.