Re: Next SWIG release

On Jan 26, David Beazley wrote:
> 
> In case anyone hasn't noticed, SWIG development has been on a bit of
> an extended winter vacation lately (after all of that template,
> namespace, typemap, and other head exploding work from last year, I
> think everyone needed a bit of a rest ;-).  However, I'm thinking
> about rolling a new release in about 5-6 weeks.  In preparation for
> that, I'd like to encourage everyone to enter bug reports on the
> sourceforge bug-tracker so we don't forget about them.  Also, if there
> are any minor feature requests, please let us know.

My standing wish for a feature request is a Ruby module only request, which is
to enable imitation of multiple inheritance (by adding methods for superclasses
that aren't the first).  

I'm not sure how minor this is, and we do have a stable workaround.  But since
you asked... :)

Discussion on this was back in June (Lyle do you remember?).


A snippet of the original request:

--------------------------------------------
Ruby doesn't support MI, but it shouldn't be too much of a stretch to supply a
workaround as SWIG has total control over how the class "looks" inside of Ruby.
 
> SWIG itself does "support" MI in the sense that it will parse class
> declarations in your SWIG interface file that use MI and the underlying type
> system saves this information. But it's up to the individual language
> modules to do something with that information, if they in fact can do
> anything reasonable. I'm not sure what would be "reasonable" for Ruby,
> though. Any suggestions?

While it makes for longer generated wrapper code, you can easily generate
wrappers as Ruby methods on the derived class in these cases, i.e.:

class Base1;
class Base2;
class Derived : public Base1, public Base2;
class OtherDerived : public Base2;

This would mean that for class Derived, the methods for Base2 would be
generated as methods on class Derived as opposed to a superclass.  For class
OtherDerived, things work as normal, and any other derived class from Base2
would still work as they currently are, unless other derived classes also use
MI.  The exception and extra wrapper generation would only kick in with the use
of multiple inheritance where the base class information is available to SWIG. 

The feature could be turned on and off, and doesn't have to be default if
necessary. 
--------------------------------------------
_______________________________________________
Swig maillist  -  Swig@xxxxxxxxxxxxxxx
http://mailman.cs.uchicago.edu/mailman/listinfo/swig