From: vor_lord@...
Date: 2003-03-15T13:43:57+09:00
Subject: Re: Limited Support for Multiple Inheritance in SWIG/Ruby

<lyle@knology.net> wrote in message
news:20030310154111.23290.qmail@webmail1.knology.net...
> All,
>
> We'd like to be able to provide support for a kind of "limited" multiple
> inheritance in SWIG's Ruby module. It is limited in the sense that, since
> Ruby doesn't support MI, we'll obviously never have the case that class
"D"
> is a direct subclass of more than one base class. However, it might be
> useful to provide support for this kind of C++ class structure:

[snip]

> The simplest solution so far seems to be to override Derived's
> #method_missing method, something like this (pseudocode):
>
>     class Derived
>       def method_missing(mth, *args)
>         for each base other than Base1
>           see if this base can handle it
>         end
>         super # call Object#method_missing
>       end
>     end
>
> but I haven't tried to implement this yet.
>
> Can someone else point out the flaws in this, and/or suggest other
> possibilities?

I realize I am way behind on this discussion (no cc's to swig, just swig-dev
of which I'm not a member) but I don't see a definite decision yet.  The
news server at work just ceased feeding comp.lang.ruby (grr) so I only catch
up here at home until they get it fixed.

I just want to indicate that I already use method_missing in my SWIG wrapped
classes for other reasons.
If this is the way you go, I suppose I could alias the old method_missing to
something, then have my new one call the old one when my code falls through.
This just seems like it would be a gotcha though, i.e. you redefine
method_missing and your MI stops working.

>That is still a possibility; the only potential drawback is that (I think)
>you'd have to wrap the non-primary base classes twice, once as a regular
>Ruby Class and once as a Module. Using the previous example, we'd wrap
>Base1, Base2, Base3 and Derived as classes, and Base2 and Base3 as modules,
>hen mix the Base2 and Base3 modules into Derived.

>This is assuming that the developer wants to be able to instantiate Base2
>and Base3 objects directly, use them as bases for other classes, and
>anything else that you'd want to do with a class. If that were *not* the
>case, I guess we could introduce a special directive that says "Wrap this
>class as a Ruby module *only*, and not as a class".

>What do you think?

I hope I'm not missing portions of this thread... I view it through
comp.lang.ruby and the threading is always screwy--(is that due to mail
clients through the ruby-talk mailing list?).  In this case it may be that
half of this is on swig-dev and not here :)

This is certainly better than my original braindead suggestion many months
ago which is to wrap the Base2 etc classes for each subclass who has it as a
secondary superclass.  I'd certainly be happy with the above.  I have a need
for both situations, i.e. when a class should only be wrapped as a module
and when it should be both.

Thanks for working on this one Lyle.  Sorry if I'm behind the 8-ball here
but this is my pet wish for SWIG Ruby.

--
Brett Williams