So I working on  little lib that's ripe for an adapter pattern, when I
see quite clearly that I have a bit of a dilemma. I have two clear
inheritance hierarchies converging. I want to create a
LinuxVideoPlayerApplication subclass, but it needs to inherit from
both VideoPlayerApplication and LinuxApplication.

  class VideoPlayerApplication < Application


  class LinuxApplication < Applicaiton

Oh no!

  class LinuxVideoPlayerApplication < VideoPlayerApplication

or

  class LinuxVideoPlayerApplication <  LinuxApplication

Ruby forces me make a choice. Which is "more real" I guess is it's
demand. But the choice is contrived. Both apply, and Ruby's strict
single-inheritance philosophy does nothing for me in the end except
make my life more complicated. One way or the other I am going to get
both behaviors in there. Period.

So as things are, I'm stuck with making one of them a module instead
of a class. But then I loose metaclass inheritance, which can be a
real pain sometimes. I become inclined to make them both modules and
use separate meta-modules if need be, to keep things nicely symmetric.
But really, why should I have to make such a fuss? Why do I have to
draw so many abstract distinctions when there is no such thing in my
actual model?

I think it would be a good idea to really give some deep consideration
as to why modules and classes are distinct in Ruby. It's clear from
Ruby's source that the distinction is self-inflicted to begin with.
Why? Are we really gaining anything by the distinction, or are we just
making things harder for ourselves w/o necessarily realizing it,
simply because that's the "philosophy".

Food for thought,
T.