The point isn't that it would break anything this time. The point is that,
in the future, changes to the API of the 'hidden' implementation classes
shouldn't break binary compatability, which might happen on some compilers
if the class signature of the implementation class is exposed. Probably it
shouldn't, as long as there are no inlined calls to it, and its not
exported. But, given the wierdness of some of the compilers we have to
support, I'd want to be careful. Better safe than sorry and all that.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
[EMAIL PROTECTED] on 01/04/2000 11:36:37 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Re: [PATCH] Make DOMString data be non-opaque in order to support
debugging
I don't see a link incompatibility, since we're not changing signatures, or
the layout of the class members or the vtable of DOMString. As long as
we're careful not to put any inline calls to the implementation in the
DOMString header, we should be O.K.
But, I'd be just as happy with the fall-back, since I do most of my
debugging in debug mode.
-Rob
Dean Roddey wrote:
>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.
