From: Trans <transfire@...>
Date: 2005-07-29T09:41:01+09:00
Subject: Re: What's so special about operators, built-in classes and modules?

matz wrote:
> When they would do almost the same thing, and when mixin inheritance
> is much simpler to understand (for me at least), far easier to
> implement, why should I implement multiple inheritance?

If I may, I don't think you should implement MI. Yet neither do I think
a differentiation between class and module is neccessary. I think this
is the common point of view of those who think calss and module should
be merged, but that view continuly gets lost in the MI talk. I'm all
for Ruby's SI with mixins, but the effects ought to be in the usage,
not in the name. Consider something like this (yes, this is made up on
the spot so don't be too hard on it).

  class Identity
    attr_accessor :username, :password, :public_key, :realname
  end

  class Location
    attr :address1, :address2, :city, :state, :zipcode
  end

One may have been happily using these classes independently for some
time, then one day decide it would be nice to REUSE them in another
class:

  class Customer
    include Identity
    include Demographic
    attr_accessor :subscriptions
  end

But of course you cannot do this. At least one of these former classes
would need to be a module. Well you _can_ WORK AROUND.

  module IdentityMod
    attr_accessor :username, :password, :public_key, :realname
  end

  class Identity
    include IdentityMod
  end

  class LocationMod
    attr :address1, :address2, :city, :state, :zipcode
  end

  class Location
    include LocationMod
  end

That'll do it. But wait since I was able to WORK AROUND it, what was
the point of preventing the original code form? Hmm? In the end it
amounts to essentially same thing. Distigushing between a class and a
module strictly by _decleration_ creates frivolous restraints. That's
why I think it better to distinguish by usage, not by name.

Thanks,
T.