I have my doubts as to how practical this would end up being in the real
world; but, if it turned out to be workable and did not cause any undue
complexity burden, I wouldn't have any argument against it. One problem
though with any such architecture, is that either it doubles the
building/testing burden, or one of the implementations never gets
built/tested by us. Either of those has non-trivial consquences. This is
one of the reasons I've fought so hard to avoid any conditional code
per-platform (or per-anything), because of just these issues.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
Curt Arnold <[EMAIL PROTECTED]> on 12/21/99 09:48:14 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: RE: PROPOSAL: DOMString
I think it is valuable to remain abstract in DOMString
since we may want to allow specific optimizations that
are not appropriate in a generic basic_string<XMLCh*>.
However, it might be possible to morph DOMString so
that it has identical semantics to a subset of
basic_string and could either be implemented as
class DOMString : private std::basic_string<XMLCh*>
{
public:
//
// override the private access of supported methods
};
-- or --
class DOMString
{
//
// a DOM specific implementation of a subset
};
This would allow both use of basic_string or DOMString
at the builders choice.
