SWIG futures

["Jason E. Stewart" <je...@ncgr.org>]

Hey,

So it is nice to be able to use SWIG to wrap the xerces project. It's
a large number of API's that can all be fairly well encapsulated in a
single command. But, there are some issues.

1) SWIG can't handle all of C++. There are a number of things, like
   operator overloading, that it can't deal with. This means that
   header files need to be munged specially for SWIG just to get it to 
   run. Then, if the lost functionality is desired you need to
   post-modify the SWIG output (such as what Harmon Nine has
   done). This is a difficult way to proceed.

2) SWIG does not do well in the perl debugger. While running test.pl
   in the debugger I get large numbers of warnings from DESTROY
   mehtods being invoked improperly, and without too much effort, I
   can get SWIG to core dump perl. 

  DB<1> $parser->parse( new FileInputSource('personal.xml'));
	(in cleanup) Not a HASH reference at
	/home/jes/work/xml-xerces/Xerces-perl/blib/lib/Xerces.pm line
	2901, <IN> line 6. 

  DB<2> $element = $parser->getDocument->getElementById(new DOMString 'one.worker');
	(in cleanup) Not a HASH reference at
	/home/jes/work/xml-xerces/Xerces-perl/blib/lib/Xerces.pm line
	2609, <IN> line 7. 
	(in cleanup) Not a HASH reference at
	/home/jes/work/xml-xerces/Xerces-perl/blib/lib/Xerces.pm line
	483, <IN> line 7. 

  DB<3> x $element->getTagName()
Signal SEGV at /usr/local/lib/perl5/5.00561/perl5db.pl line 1246
	DB::eval called at /usr/local/lib/perl5/5.00561/perl5db.pl line 1140
	DB::DB called at /home/jes/work/xml-xerces/Xerces-perl/test.pl line 25

Debugger aborted

3) SWIG provides only a generic interface that copies the C++
   interface. In many cases there is a much smarter way to do things
   in perl, but SWIG copies over the class hierarchy and methods
   exactly as they are in C++. For example it would be trivial in perl 
   to make all methods that expect DOMStrings handle string constants
   as well. But all these modifications would be lost next time you
   ran SWIG.

For me, I could deal with the first and the third, but the second is a death
sentence. I do 50% of my development in the perl debugger. Is there
some documented way to use a SWIG-ified module in the debugger? Does
anyone else have this problem?

It could prove very time consuming to produce a Xerces perl interface
by hand, but it could have a number of benefits besides those
above. One big difference is that the module could be easily split
into multiple separate modules: Xerces::DOM, Xerces::DOM2,
Xerces::SAX, etc. This would speed script loading and execution and
make the modules easier to handle.

I've written a large perl module that uses XS and C++ to interface a
large C++ graphics library (the Pad++ project), and it was
simultaneously a joy to use perl and XS and a pain in the butt. SWIG
is certainly much simpler, but if I can't use Xerces from within the
perl debugger, than I'm forced to implement it via XS.

ideas?

jas.