It might not be quite that simple. A major reason for the DOM having opaque
implementation classes is so that the implementations can be changed
without breaking binary compabitility. I'm not sure if that will remain the
case on all compilers once you move the class definition out to the header.
If it doesn't cause this problem, then I got no problem with it. But, if it
does, we might need to consider some other way to achieve this result.
One posibility would be to put those two little classes in a separate
header. In debug mode, include it into the DOMString header. In release
mode, include it back into the DOMString Cpp file in order to insure that
binary compatability issues are not compromised.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
[EMAIL PROTECTED] on 01/03/2000 09:43:25 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: [PATCH] Make DOMString data be non-opaque in order to support
debugging
Here's the problem:
A DOMString object holds a pointer to a DOMStringHandle object, which holds
a pointer to a DOMStringData object, which holds the actual character array
of the string. DOMString.hpp uses an opaque pointer/Cheshire Cat pattern
to hide the implementation of DOMString. This is good, old-fashioned
information hiding. But in this case, it hides too much, information that
is crucial to debugging with DOM, namely the contents of the underlying
character array. Perhaps other platforms are different, but with MSVC++,
you can't see the value of DOMString's in the debugger. This sucks,
especially for programs like Xalan which use DOMString heavily.
