Ken Collins <ken@metaskills.net>

In the last case where you opened up the classs. Poor form? What
about the ability to reflect on how a class is extended? For instance
ActiveRecord::Base.included_modules and/or ActiveRecord::Base.extended_by.
Opening up classes looks the ability for reflection to how it was changed.

Here is a snippet of code below to expand on my point. I just found out
that the class method extended_by comes from ActiveSupport (I think) but
it's not vanilla ruby. So maybe this is where the pattern evolved. IE,
by using included and letting include do the extend, we are able to reflect
on how us/others have extended the class. Which is funny, because the
english of it should be allowed. Hence is there a default Ruby way to
reflect on extended?

All of what your saying might make sense for one’s own lib and code
organization. Like for instance, the author of ActiveRecord might
just follow your simple pattern at the top and by the time I load up
ActiveRecord::Base and asks for it’s included modules, I get a clean
slate of [Kernel] which makes the default idiom (which yes does not
match english) work. Thoughts?



class SomebodyElsesLib

end

module MetaSkills
  module KillerFeature

    def self.inlcuded(klass)
      klass.class_eval do
        extend ClassMethods
        include InstanceMethods
      end
    end

    module InstanceMethods

      def killa_instance
        'instance'
      end

    end

    module ClassMethods

      def acts_as_killa
        'class'
      end

    end

  end
end

SomebodyElsesLib.send :include, MetaSkills::KillerFeature

SomebodyElsesLib.included_modules # => [MetaSkills::KillerFeature, Kernel]
SomebodyElsesLib.extended_by      # ~> -:40: undefined method `extended_by' for SomebodyElsesLib:Class (NoMethodError)