From: Stu <stu@...>
Date: 2012-11-05T18:31:12+09:00
Subject: Re: Support for multiple Inheritance by classes

Multiple Inheritance is the GOTO statement of object oriented
programming -- sort of a caveat emptor to people new to the paradigm
coming from a procedural language background.

Module/mix-in would work as far as conceptually. If it's a daemon, as
the so called example used, a system level service. The paradigm
changes. In UNIX not everything is an object. Formally taught to
sysadmins that everything is a file which really really means
everything is a stream of bytes( i.e. C Programming and system
kernel/shell)... This is why Kernel in ruby is a module and not a
class.

I can't think of one reason why multiple inheritance would be useful
for daemon process. Updating based on changes can be accomplished
through creating wrappers to the signals much the same way rc.d/init.d
is. Inside ruby you have access to message passing much the same as
you would expect from any object oriented language.

Ultimately there is nothing wrong with wanting a feature. Consider it
a challenge to work within the context of the language or hack up your
own dsl. MI is not the panacea that early oops language designers
thought it would be. There most certainly is a better way to deal with
various problems and solutions.

Also it's not a "work around" to use Mix-in Modules as the op
suggested. It's actually the preferred and correct way i.e. the Ruby
way. Hit up a couple non object oriented languages and move data back
and forth there. That is the only way to gain enough insight to know
what is a "work around" vs the concept of "working with". The
limitations are not with the ruby language or interpreter. It's with
the users who superimposes such limitations upon themselves.

For one reason or another this thread reminded me of the Execution In
Kingdom of Nouns

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html