On 6/11/06, Yukihiro Matsumoto <matz / ruby-lang.org> wrote:
> Hi,
>
> In message "Re: Why the lack of mixing-in support for Class methods?"
>     on Sun, 11 Jun 2006 22:43:11 +0900, transfire / gmail.com writes:
>
> |As you say, meta-programming can take care of it, but the biggest
> |problem with meta-programming approaches is that everyone is using
> |there own variation.
>
> Don't get me wrong.  I didn't say that I wouldn't do nothing, and let
> you help yourself using meta-programming features.  I'd happy to add
> the standard feature to achieve your goal, if it really is a generic
> requirement.  I like the solution that Daniel has shown in
> [ruby-talk:196730].
>
> The point is I want to make sure which approach is the way to go.
>
>                                                         matz.
>
>

IMHO, the best approach in this thread is the access-control style
notation suggested by transfire:

>   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.

While this certainly needs to be thought about and refined, I think a
good implementation will not only answer the need at hand, but also
contribute to the cohesiveness of the mixin concept, while planting
the locus of control firmly within the mixin module.

I.e. it's a very elegant way for the mixin module to determine exactly
what functionality gets included in the reciever, whether it is the
default instance methods, a combination of instance methods and class
methods, maybe even just the class methods, or some subset of instance
methods and class methods. Very nice in and of itself, if provided
with a sensible default which would implicitly do the right thing for
common uses.

It also avoids what I see as the major problem with adding #import:
the degradation of the cohesiveness of the inclusion concept. We
understand what it means when a class #includes Enumerable right now.
But what meaning would we ascribe to it #importing Enumerable? How is
#import different from #include?  Would we now need to check both
where we before checked only for inclusion?  And what if we allow the
reciever to ask only for the class methods?  Thus the neat mixin
concept risks sprouting too many special cases so as to become
meaningless. Transfire's suggestion keeps it cohesive.

Another nice thing: it resembles the access control syntax
(public/protected/private) which is conceptually similar to inclusion
control.

-- 
-Alder