From: transfire@...
Date: 2006-06-10T21:24:02+09:00
Subject: Re: Why the lack of mixing-in support for Class methods?

>> I'm still leaning towards having just one method, include, that is
>> available to client classes to "use" the module in typical cases. The
>> module decides what gets included at the instance and class levels.
>
> The major lack right now is a way to "include" module methods. Even if
> the module is to be the one deciding which methods get exported, it
> does not have a straightforward way to export its own self-methods.

I am suddenly reminded of the idea non-inherited methods --a way to
sepcify that a method is not be inherited through sublcassing or
inclusion. The idea being that some methods might just exist to serve
other methods and should not be apart of the class/module's interface
at all, not even for subclasses --sort of a "superprivate". So if we
further extrapolate, this concept allows control of what a module will
provide upon inclusion at the instance level. Might we not do the same
at the class level, but in the the case of a module we need the
opposite control (because the default is not to "extend") --a sort of
"superpublic".

  module M
    class << self
      def foo ; end
      extensible
      def bar ; end
    end
    def bar ; end
    uninheritable
    def foo ; end
  end

  Class X
    include M
  end

  X.foo  #=> error
  X.bar  #=> nil
  X.new.foo  #=> error
  X.new.bar  #=> nil

This way then we need only use #include for all forms of "bevahiorial
importing" and it is up to the module/class to decide what it provides
--where the responsibility really belongs.

T.