On 10/5/07, Trans <transfire / gmail.com> wrote:
> 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.

I think that you've got a problem here, and it won't be solved with MI.
You need to reapproach the issue. I have yet to find a time when MI
makes sense even in C++.

>   class VideoPlayerApplication < Application
>   class LinuxApplication < Application
>
> Oh no!
>
>   class LinuxVideoPlayerApplication < VideoPlayerApplication
> or
>   class LinuxVideoPlayerApplication <  LinuxApplication

Frankly, I don't think you've got a good design here, without seeing
anything else.

A LinuxApplication isn't sensible. What makes a LinuxApplication
different from a GenericApplication or from a WindowsApplication? In
other words, I think that you've set yourself up for the dichotomy by
not considering this the right way.

Think of it in terms of aspects. What are the aspects that make an
application a Linux application? How can you pull those in cleanly?


> 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.

That's fine, but nothing you've written suggests that MI is a good idea.

> So as things are, I'm stuck with making one of them a module instead
> of a class.

Why?

Avoid inheritance when you don't need it -- and you need it a lot less
than you think. Composition is usually a better approach than
inheritance.

> 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?

Why are you choosing to implement this in perhaps the worst OO way
possible? Why have you made metaclass inheritance important? Again:
consider composition.

> 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,

I'm sending it back. It's overcooked and watery.

-austin
-- 
Austin Ziegler * halostatue / gmail.com * http://www.halostatue.ca/
               * austin / halostatue.ca * http://www.halostatue.ca/feed/
               * austin / zieglers.ca