On Sat, 6 Oct 2007 06:06:45 +0900, Trans <transfire / gmail.com> wrote:
> I think it would be a good idea to really give some deep consideration
> as to why modules and classes are distinct in Ruby. Why?

One reason is to avoid ambiguity about object representations.  Let's
say that instance methods of class A assume one representation, and the
instance methods of class B assume another, incompatible, representation
[1].

 class C < A, B
 end

Should A's methods or B's methods break when called on an instance of
C?

One solution I can think of immediately would be for a newly allocated
instance of C to allocate an instance of A and an instance of B behind
the scenes, delegating method calls to them as appropriate.

However, at that point it's starting to sound suspiciously like
aggregation... have you considered using aggregation rather than just
inheritance for modeling your problem?

-mental

[1] In Ruby 1.8, representations can be incompatible because they either
    used instance variables with conflicting names, or because they are
    of different RBasic types -- e.g. T_STRUCT versus T_DATA