From: ara.t.howard@...
Date: 2006-06-09T23:54:40+09:00
Subject: Re: Why the lack of mixing-in support for Class methods?

On Fri, 9 Jun 2006 dblack@wobblini.net wrote:

> I know (believe me, I've been through many iterations of this discussion :-)
> What I really mean is: I don't see what's wrong with:
>
>  module SomeMethodsIWantSomeClassesToHave
>  end
>
>  module SomeInstanceMethods
>  end
>
>  class C
>    extend SomeMethodsIWantSomeClassesToHave
>    include InstanceMethods
>  end
>
> In other words, I prefer a module design that doesn't fuse different
> modularities together in the first place.

sometimes they belong together logically:

   module Sync
     require 'sync'

     def self.sync m, which = :EX
       module_eval <<-code
         alias_method "__#{ m }__", "#{ m }"

         def #{ m }(*a, &b)
           sync_init
           synchronize(:#{ which }){ __#{ m }__(*a, &b) }
         end
       code
     end

     def sync_init
       extend Sync_m unless Sync_m === self
     end
   end

   class C
     import Sync
     sync 'method_that_needs_to_be_thread_safe'
     sync 'another_method_that_needs_to_be_thread_safe', :SH
   end

obviously one can break them apart, but it's un-natural.  in general anytime
the imported module introduced instance methods which rely on class state or
class methods or, as this case does, introduces class methods which rely in
instance state/methods, it makes logical sense to keep it all in one bundle.
for me logical orthogonality is by far ruby's greatest asset and i hate doing
illogical things in my ruby code - i save that for fortran.

in any case i don't think anyone thinks anything is 'wrong' with splitting it
up, but it clearly violates DRY to do this

   module M
     module ClassMethods
     end
     module InstanceMethods
     end
   end
   class A
     include M::InstanceMethods
     extend M::ClassMethods
   end
   class B
     include M::InstanceMethods
     extend M::ClassMethods
   end
   class C
     include M::InstanceMethods
     extend M::ClassMethods
   end

vs this

   module M
     module ClassMethods
     end
     module InstanceMethods
     end
     def self.included other
       other.extend ClassMethods
       other.module_eval{ include InstanceMethods }
     end
   end
   class A
     include M
   end
   class B
     include M
   end
   class C
     include M
   end

plus, the first case is annoying.  if it weren't, people wouldn't be rolling
their own shortcuts left and right - which is kind of what this thread is
about.

kind regards.

-a
-- 
suffering increases your inner strength.  also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama