[Wxruby-dev] RE: SWIG Question

[Curt Hibbs]

Thank you very much Lyle for your extensive and informative reply. I have
interspersed a few comments below...

> -----Original Message-----
> From: Lyle Johnson [mailto:address@hidden
> Sent: Wednesday, September 11, 2002 6:58 PM
> To: Curt Hibbs
> Cc: Bob Calco; wxRuby; address@hidden
> Subject: Re: SWIG Question
>
>
> Curt Hibbs wrote:
>
> >I looked at what the Python people did with SWIG to produce
> wxPython, and I
> >looked at what you did to produce FXRuby, and this have left me with a
> >nagging question: is it really necessary to duplicate the all of the
> >underlying library's constants and such in the interface files
> when SWIG is
> >supposed to be able to process C/C++ header files and figure
> that stuff out
> >itself?
> >
> It is possible that, with the latest versions of SWIG, this may no
> longer be necessary. You need to know that, for example, wxPython was
> developed using SWIG 1.1, which didn't include a preprocessor and a
> number of other advanced features that SWIG 1.3 has. Similarly, when I
> began development of FXRuby (using a very early SWIG 1.3 release) it was
> missing a lot of the functionality that is currently available. One such
> feature that immediately comes to mind is the recently added support for
> overloaded methods; in earlier versions of FXRuby, I was having to "roll
> my own" version of overloading to make it work. When Dave (Beazley) got
> overloading working for SWIG 1.3.14, I was able to remove a lot of that
> cruft from FXRuby.


Great! I was hoping that a lot of what I was seeing was historical remnants.


> >Duplicating the header file definitions in the interface files
> seems like a
> >potential maintenance headache. Every time the underlying
> library changes,
> >you'd have to do a diff to see what changed and then manually make those
> >changes in the interface files.
> >
> Agreed, this is a maintenance problem, so you should avoid it
> when possible.
>
> >My ideal would be to not have to create any interface files at
> all. Instead,
> >I would like to have SWIG process the library's header files to create a
> >"raw" ruby binding to the library. And then, on top of that,
> create a layer
> >of Ruby code that presents a more Rubyesque api to the outside world.
> >
> I have used a similar approach for other libraries, and it works quite
> well. In fact, though most of FXRuby is implemented in the extension
> module's shared library, some of the code is implemented in Ruby. My
> Ruby interface to CLIPS took this approach as well, wrapping the
> low-level C functions and then building an object-oriented interface in
> Ruby that calls those functions under the hood.


Excellent. I think, then, that it would be prudent for us to proceed this
way (in general) and deal with problems that arise on a case-by-case basis.


> >But the fact that both wxPython and FXRuby have created
> extensive interface
> >files tells me that I must be missing something -- that there is
> something
> >important that I don't know.
> >
> There are some things that SWIG still doesn't do (and, to be fair,
> perhaps can't do in an automated way).
>
> For example, one of my requirements for FXRuby is that you should be
> able to derive new Ruby classes from the (wrapped) FOX classes and
> override their virtual functions, and everything "just works". Let's say
> you want to implement a new layout manager for FOX, and you decide to
> subclass FXCompsite to get started:
>
>     class MyLayoutManager < FXComposite
>     end
>
> Since some of the key functions involved in layout are the C++ virtual
> functions layout(), getDefaultWidth() and getDefaultHeight(), you'll
> probably need to override them to do the right thing for your layout
> manager:
>
>     class MyLayoutManager < FXComposite
>         def layout
>             # Lay out my child widgets
>         end
>         def getDefaultWidth
>             # Return the default width for this window
>         end
>         def getDefaultHeight
>             # Return the default height for this window
>         end
>     end
>
> Unfortunately, it's not that simple. You can create an instance of
> MyLayoutManager and use it, all right, but underneath it's still just an
> FXComposite as far as FOX is concerned. Why? Because there's no C++
> inheritance involved. That is to say, when some object calls the
> object's virtual getDefaultWidth() function in C++-land, it's going to
> stop when it reaches FXComposite::getDefaultWidth(). The painful reality
> is that, for this virtual function dispatch to work, you must derive new
> C++ classes for any C++ class that has virtual functions that you want
> to override. I'll stop here for now, but there's a lot more to say about
> the topic ;)


Yes, I can see the issues involved.

I think the approach I want to take can avoid this. I'm not really
interested in presenting the wxWindows api "as is" to the Ruby programmer.
What I want to do is to treat wxWindows as the "platform primitives" upon
which the Ruby api is based. As such, I would have no requirement to be able
to extend the wxWindows classes in Ruby as I would not directly expose those
classes. Instead, the classes that implement the Ruby api would be
extendable.


> Another issue is interaction with Ruby's garbage collector. As you may
> know, Ruby uses a "mark and sweep" GC algorithm that extension writers
> must pay attention to. If one of your Ruby objects holds references to
> other objects, you need to provide a function that "marks" those objects
> as reachable so the garbage collector won't clobber them prematurely.
> This, again, is not something that can be determined automatically by
> SWIG; you pretty much need to be familiar enough with the library to
> know which function calls cause new references to be saved (or released).


I'm hoping that keeping as much of the code in Ruby as possible will make
this a little easier.


> >So, my question is: is there some reason why the approach I
> outlined above
> >won't work?
> >
> Not necessarily. The approach you've outlined will work for a lot of
> cases, and it's the one I use when I have the option. I'm not familiar
> enough with wxWindows enough to know how much of a problem the issues I
> identified are going to affect your decision. But Robin Dunn (the
> original developer of wxPython) is a pretty sharp guy, and I suspect
> that to get the full wxWindows "experience" you may have to make a
> similar investment.


Thanks again, Lyle -- this really helped a lot!

Curt