"there’s no need for a MyMod::InstanceMethods since methods on MyMod are already in the chain."
There are no need for InstanceMethods in the original module either. They are included when the module is included.
"So far ActiveSupport::Concern has taken away some of the boilerplate code used in the pattern: no need to define an included hook"
Yet he still use such a hook, even if it has become an instance method call instead of a class method call.
", no need to extend the target class with ClassMethods, no need to class_eval on the target class."
Sure, the extend call is automated away (at the cost of adding a line like "include ActiveSupport::Concern".
But there are also no reason to do class eval in this context - just call the method directly.
The deferred usage of self.included does seem a bit useful though, and that is where the article should have started as everything above that is a strawman.
There are no need for InstanceMethods in the original module either. They are included when the module is included.
"So far ActiveSupport::Concern has taken away some of the boilerplate code used in the pattern: no need to define an included hook"
Yet he still use such a hook, even if it has become an instance method call instead of a class method call.
", no need to extend the target class with ClassMethods, no need to class_eval on the target class."
Sure, the extend call is automated away (at the cost of adding a line like "include ActiveSupport::Concern".
But there are also no reason to do class eval in this context - just call the method directly.
The deferred usage of self.included does seem a bit useful though, and that is where the article should have started as everything above that is a strawman.