"Paul Warren" <[EMAIL PROTECTED]> writes: > On Thu, Jan 24, 2002 at 09:33:18AM -0700, Jason E. Stewart wrote: > > PS. the issue with SWIG-1.3 is still important, but as long as you can > > use IDOM, I can fix that in a few weeks (after my conference is > > over). Could you enter a bug for it in Bugzilla: > > > > http://nagoya.apache.org/bugzilla/enter_bug.cgi?product=Xerces-P > > > > You'll have to register first, but I'd really appreciate it. > > I will do, but I'm still keen to get this working as I'm trying to make > Pathan play with SWIG.
Yes, I think this is a really valuable effort, and I will support you in any way I can. Getting XML::Xerces to interact with other modules is critical. My current constraints limit me to 15' of Xerces time/day until Feb 2, after that, and I'm much freer. > I have managed to build a Pathan Perl module, which seems to build and > load OK, but the problem that I have is that I then need to pass > DOM_Nodes etc. to Pathan methods. When I try this, the SWIG code I have > generated, quite reasonably, does not recognise the > XML::Xerces::DOM_Node not as being a DOM_Node. I think that the > solution may lie in %importing the Xerces.i file into the Pathan.i file. It's likely not to be so simple. SWIG has a rather brutish way of dealing with inheritance. The key issue is not getting the Pathan code to know about Xerces, but the other way around, getting Xerces to know about Pathan -- which is impossible! SWIG hard-codes all known subclasses at compile time, so if I want to add in a new module that uses Xerces the already compiled XML::Xerces doesn't know about the new Pathan subclass and it complains. To get around this, I hacked the SWIG method that checks inheritance, and instead of using the built-in (brutish) method, I have it use Perl's isa() method instead. This works but has some drawbacks: 1) you must ensure that if you make a subclass of DOM_Node (or IDOM_Node) that you invoke the C++ class constructor for IDOM_Node (or some C++ subclass of IDOM_Node). Because SWIG assumes that it will find a pointer to that class object and attempt to dereference it - if there isn't a pointer there, and since I've gone around SWIG's inheritance checker, you'll get a quick and nasty segfault. 2) When you get back information via SWIG, it has hard-coded the class of the return object into the API at compile time. So for example, if you add some Pathan::IDOM_Node subclass to IDOM_Node, and use the getElemenstByTagName() method, you will get back XML::Xerces::IDOM_Element nodes and not Pathan::IDOM_Node's. There might be a way around this. Normally, using getElemenstByTagName() SWIG would only return XML::Xerces::IDOM_Node's which is silly, so we added a method to recast the objects based on what they really were under-the-hood called actual_cast() which is defined in Xerces.pm. So you may be able to have your Pathan::IDOM_Node subclasses set their node-type attribute to be something above the current Xerces node-type range, and in XML::Patan you can overload the IDOM_Node::actual_cast() method to accept your new node types. HTH, jas. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
