On Thu, 28 Jul 2005, Daniel Brockman wrote:

> That is a reasonable belief.  Indeed, I'm not completely sure myself that
> unification would reduce net confusion.  So I'd be interested in seeing some
> arguments.

well - classes can't do this

   module MainHelper
     ...
   end

   module SetupMain
     include MainHelper
     def run
       ...
     end
   end

   module QueryMain
     include MainHelper
     def run
       ...
     end
   end

   module BackupMain
     include MainHelper
     def run
       ...
     end
   end

   class Main
     def main
       table = {
         SETUP => SetupMain,
         QUERY => QueryMain,
         BACKUP => BackupMain,
       }
       modul = table[ mode ]
       extend modul
       run
     end
   end

this sort of aggregation can be very nice for source management when classes
are growing large - one can simply make the class be what it needs to be and
nothing more.  in short - classes do not support ad hoc aggreation, which is
very nice feature to give up.

>
> Here is an example of an argument:
>
> Whenever you bring up the issue of modules vs. classes,
> there will generally be at least one person who believes
> that including a module is the same as copying its body.
> This confusion would go away if the two were unified.

this is a similar 'argument':

   in c most people think that a definition like

     int foobar (const char * string);

   will prevent people from modifiying string.  it won't.  for that one needs

     int foobar (const char * const string);

   why not unify them?

the answer is obvious: because they are differnet.  a focus on clarifying
doccumentation might be wiser in this case.  and, in the end, certain people
are simply going to have to be told to rtfm - not everything can be intuitive
AND powerful.

>> That's not instantiating a module. It's cute, but it's not
>> instantiating a module.
>
> Of course it's not instantiating a module, but it's pretty
> much _as good as_ instantiating a module.  It lets you use
> modules instead of classes, which demonstrates that the
> distinction is superficial.

does it?

   harp:~ > cat a.rb
   class Module
     def new(*a, &b)
       (@__klass__ ||= (m = self and Class::new{ include m }))::new(*a, &b)
     end
   end

   module M
     class << self
       def class_method
         42
       end
     end
     def instance_method
       42
     end
   end

   m = M::new
   p m.instance_method
   p m.class.class_method

   harp:~ > ruby a.rb
   42
   a.rb:21: undefined method `class_method' for #<Class:0xb75d0480> (NoMethodError)

and, of course, you still can't inherit from M - but i realize this needed be
so.

i think i'm with austin on this one.

cheers.

-a
-- 
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| My religion is very simple.  My religion is kindness.
| --Tenzin Gyatso
===============================================================================