On Sunday 26 October 2008 12:48, lkcl wrote: > jim, hi, > > https://bugs.kde.org/show_bug.cgi?id=172740 > > the maintainers of the khtmlpart have agreed to add an enum to uniquely > identify every single object derived from Node, which should help. > > are you _sure_ it's to do with twine - twine is going to have to be > _seriously_ sophisticated, to understand the inter-relationships between > Node* derived classes, such that even when you do > getElementById("something") from the python bindings, an e.g. > DOM.HTMLElementBody class or a DOM.HTMLTableElement (or whatever) is > returned, not a DOM.Node object, and also to be able to maintain a > one-to-one and onto mapping between c++ and python objects. > > i'll be dead-impressed if it does. _really_ impressed.
Don't be impressed - it's pretty simple. Twine collects all of the inheritance information as it parses the h files. The project file specifies which base classes to generate sip %ConvertToSubClassCode blocks for and then generates that code from the inheritance hierarchy. That's the code that does object promotion, say for a factory which always returns a QObject no matter what QObject descendant it creates. (twine could just generate %ConvertToSubClassCode blocks for any inheritance relationships, but for some reason I don't recall - dating to twine's predecessor presip, which did the same stuff - it isn't desireable to do that for every possibility) In terms of twine, the enum won't make any difference unless twine is modified to use it - twine generates PyKDE code that uses dynamic_cast<> to work back up the inheritance tree to find the highest level class an object is derived from (because, as in the current case with DOM::Node, not all KDE objects can be interrogated for inheritance info). If RTTI is turned off when compiling, then dynamic_cast won't work though. The bug in twine is that no hierarchy whose base class is declared in a namespace (like DOM::Node) is handled correctly. Non-namespaced base classes (like QObject) work fine. It's some bug in the way fully-qualified names are handled - I haven't looked into it because Simon is maintaining twine now, and it isn't obvious just from looking at the code. It's all done in twine/plugins/subclass.py. JIm _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
