> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Friday, November 19, 1999 2:36 AM > To: [EMAIL PROTECTED] > Subject: Re: Request for Vote: Dom Package Change > > > > > > Robert Weir wrote: > > >And that brings out another issue: we lack an abstract DOM > in C++. The > >org.w3c.dom.Node, etc. Java classes are interfaces, so you > can at least > >imagine having several tuned implementations. But the C++ > dom\DOM_Node > >class is a non-abstract, non-polymorphic wrapper of > NodeImpl. I think it > >would be grand if we had a set of abstract base classes for > DOM_Node, etc. > >Would this cause an especially bad performance hit, adding a > vtable to > each > >node? > > > Yea, I know. I'm not very happy with the lack of an abstract, > polymorphic > interface corresponding to the official W3C DOM API either. > > C++ makes it hard to get everything you might want. > > If you try to make the DOM_* classes have virtual functions and > inherit abstract interfaces, several things go bad. It becomes > much less efficient to pass these types around by value (they > all consist simply of a single pointer now), the temptation > to pass them by C++ pointer or reference becomes irresistible, and > keeping the reference counting memory management robust then > falls apart. > > Another problem surfaces in keeping binary compatibility > of applications with revised DLLs. With all calls from application > code to the DOM being non-virtual, and with the virtual dispatch > happening only within the XML DLL, we have pretty good ability > to fix bugs and build a new, fully binary compatible DLLs. Once > vtable structure and real object layout leaks into the compiled > application code, this becomes much much harder to do. For us > at IBM, this problem is all too real. > > Java, of course, has the right solution to all of these problems. > > If we were to do a version of the C++ DOM with proper abstract > interfaces, I'd be tempted to consider going with manual > memory management, and having the user code work directly > with C++ pointers or object references. But with the DOM structures > being so heavily intertwined - every node has document, parent > sibling and child pointers, and may be in some heaven knows > what node lists or maps - memory management is going to be > hard to do. Unless it is done at a very coarse level, like > at the entire document level. > > Too many tradeoffs. No easy answers. > > -- Andy > >
Why would the virtual functions have to be at the DOM_* level? The DOM_* classes are just handle classes now so wouldn't it be possible to create an AbstractNodeImpl with all pure virtual functions and then derive XercesNodeImpl from that? Other implementations could then be added by creating, for example, JoeNodeImpl. If you did this for all the *Impl classes then you would just need a mechanism to choose which DocumentImpl to load at runtime. This would require some large changes to the current code base. For example, NodeImpl currently holds a DocumentImpl *. This would have to be changed to a DOM_Document or AbstractDocumentImpl. -joe
