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.


Reply via email to